Re: reiser4 plugins

[Markus Törnqvist]

On Fri, Jun 24, 2005 at 11:41:21AM +0100, Alan Cox wrote:
>
>More fundamentally - prototype things *out* of the main kernel. If
>everyone was doing their prototyping in kernel Andrew Morton would by
>now be a team of about 25

This is going semi off-topic but how then do you justify regression
that's apparently confessed? :)

It appears -mm is more of a prototype tree than a development tree;
I remember Con Kolivas cursing (with SMP nice support) that the
interface is too lively to keep supporting one patch. Unfortunately
I can't find the original post I'm thinking about but
http://lkml.org/lkml/2005/5/16/68 says essentially the same thing.

There's also my all-time favorite, http://lkml.org/lkml/2005/3/14/4

The lack of QA seems appalling here, and I'm sure Reiser has had
to do more of that for DARPA than most linux kernel hackers around.

What I'm saying here is isn't it a bit hypocritic to ramble on that
we need real assurances for this to work, community proof and bugfixes
on the list mean nothing, when other core systems seem to be much
looser in this respect?

Sure, "other people merge design-breakers and bugs" is NOT a justification
for merging Reiser4, of course, but Reiser4's track record has vastly
cleaned itself up.

Most bug reports come from broken hardware or unsupported patches or
old code. Just have Namesys swear they won't introduce design changes
until the userland utils are available, and won't do it at all after
EXPERIMENTAL has been removed.
They already did this with changes that require mkfs :>

Here's a real suggestion, for LKML et al, dropping the sarcastic mode.

0. Namesys addresses the code beautification reqs mentioned here earlier.

1. Merge Reiser4 sans metas into 2.6.13.
2. Namesys can have a separate metas patch for testing.
3. Gradually merge Reiser4 architecture into VFS and if this really
   requires a 2.7, as (iirc) Valdis Kletnieks suggested, make it so.
   Might do the rest of the kernel some good too.

The above is a lame compromise; I'd much rather have the meta system
in, as is dropping the stupid name, ..metas/ is better, and dropping "meta
files can have meta data, ie. endless recursion in ..metas/

Then it can be merged into the VFS as needed, but if there truly are issues 
left, I realize it can't probably be fixed fast enough.

Having metas on by default probably leads to a lot of bug reports,
which get fixed, and at the same time makes VFS-merging easier,
when metas-related bug issues are fixed in VFS.

My two grumpy cents.

-- 
mjt

Attachment: signature.asc
Description: Digital signature