Re: List of things requested by lkml for reiser4 inclusion (to review)

[Andrew Morton <akpm@osdl.org>]

Hans Reiser <reiser@namesys.com> wrote:
>
> ...
>
> Do I remember right that the submission
> deadline is a week from Monday for 2.6.14 inclusion?

Next week, supposedly.

But something like a brand new filesystem can go in pretty much any time,
as long as it compiles.  Because it can't break anyone's current setup.

Brand new filesystems which also require monkeying with the core VFS aren't
quite that straightforward though.

> 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.

Guys, you should know by now not to send 1021-column emails :(

> 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?

I'd prefer that unused code simply not be present in the tree, sorry.

> 
> 
> 2. dependency on 4k stack turned off
> 
>    removed as requested

So it all runs OK with 4k stacks now?

> 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.

kcond is only used in a couple of places.  One looks like it could use
complete() and the other is a standard wait-for-something-to-do kernel
thread loop, which we open-code without any fuss in lots of places
(kjournald, loop, pdflush, etc).  So yes, I'd be inclined to remove kcond
please.

Also, it would be better to use the kthread API rather than open-coding
kernel_thread() calls.  If you think that reiser4 needs additional ways of
controlling kernel threads then feel free to enhance the kthread API.

> 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?

The type-unsafety of existing list_heads gives me conniptions too.  Yes,
it'd be nice to have a type-safe version available.

That being said, I don't see why such a thing cannot be a wrapper around
the existing list_head functions.  Yes, there will be some ghastly
C-templates-via-CPP stuff, best avoided by not looking at the file ;)

We should aim for a complete 1:1 relationship between list_heads and
type-safe lists.  So people know what they're called, know how they work,
etc.  We shouldn't go adding things called rx_event_list_pop_back() when
everyone has learned the existing list API.

Of course, it would have been better to do this work as a completely
separate kernel feature rather than bundling it with a filesystem.  If this
isn't a thing your team wants to take on now then yes, I'd be inclined to
switch reiser4 to list_heads.


> 
> 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,

We think this person didn't submit a patch to remove the 124 assertions
from ext3 ;)   Keep the assertions.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/