Features Download
From: Hans Reiser <reiser <at> namesys.com>
Subject: List of things requested by lkml for reiser4 inclusion (to review)
Newsgroups: gmane.comp.file-systems.reiserfs.general
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

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

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.


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


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

    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?
CD: 3ms