We haven't been sending much email out, but we have been working away.
We just finished the VFS work, and will send a patch out on Monday.
akpm asked for a bullet list of things suggested on lkml as issues for
inclusion.
There are some things that I would like akpm to confirm represent the
official opinion/consensus as opposed to just someone posting an opinion
and perhaps not being right. I assure you that all points made by
commenters were considered carefully, and I thank all of them for their
time.
If we lose every remaining point of this list, we can generate a patch
in a few days, because the VFS work was the only substantive (in coding
hours) task, and it is done. Do I remember right that the submission
deadline is a week from Monday for 2.6.14 inclusion?
This is supposed to be a bullet list, so I don't list here the line by
line minor code improvements sent to us, most of which were
incorporated, but let me take a moment to thanks those who donated them.
Hans
1. pseudo files or "...." files
disabled. It remains a point of (extraordinary) contention as to whether it can be fixed, we want to keep the code around until we can devote proper resources into proving it can be (or until we fail to prove it can be and remove it). We don't want to delay the rest of the code for that proof, but we still think it can be done (by several different ways of which we need to select one and make it work.) Let us postpone contention on this until the existence of a patch that cannot crash makes contention purposeful, shall we?
2. dependency on 4k stack turned off
removed as requested
3. remove conditional variable code, use wait queues instead.
not done. There are times when reduced functionality aids debugging. kcond is (literally) textbook code.
We don't care enough to fight much for it, but akpm, what is your opinion? Will remove if akpm asks us to.
4. remove reiser4_drop_inode
done.
5. remove undesired abstraction layer right below reiser4 VFS hooks.
done. This was a big job just completed.
6. remove type safe lists and type safe hash queues.
not done, it is not clear that the person asking for this represents a unified consensus of lkml. Other persons instead asked that it just be moved out of reiser4 code into the generic kernel code, which implies they did not object to it. There are many who like being type safe. Akpm, what do you yourself think?
7. remove fs/reiser4/lib.h:/div64_32.
is being replaced by the linux one.
8. Remove all assertions because they clutter the code and make it hard to read
We think this person was not an experienced security specialist, and that what we do is considered by professional code auditors to be laudable practice. We can supply an emacs macro that makes them greyed out. I myself found the assertions to be distracting at first (though functional and especially necessary for a DARPA funded project), and then after time got used to them, and now I understand that it was just my inexperience that caused the discomfort. I now have a more sophisticated subconscious that is not discomforted or distracted by them. People debugging find them very useful. Defense branches tear their hair out at how difficult it is to get the commercial software they use coded this way, and I think they are right to be frustrated. Linux kernel folks, those DoD guys actually know quite a few things about security, maybe its ok that they taught me something and the code reflects that? We will conform on this if requested to by akpm, but somehow I doubt he will quite honestly. akpm?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |