Subject: List of things requested by lkml for reiser4 inclusion (to review)
Date: Friday 9th September 2005 17:36:06 UTC (over 12 years ago)
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?