login
Search
Hans Reiser [interview] sent an email to the lkml titled, "I request inclusion of reiser4 in the mainline kernel". He provided a list of objections raised earlier, noting that all had been addressed. Among the listed issues, Reiser4 now works with 4k stacks. "There have been no bug reports concerning the new code," Hans added.
The request was followed with some suggestions by Christoph Hellwig, including general comments about the coding style. This was one of many issues that led to debate in which Hans commented, "most of my customers remark that Namesys code is head and shoulders above the rest of the kernel code. So yes, it is different." Alan Cox [interview] replied that while the kernel coding style isn't his own style, he tries to follow it when working on the kernel, "one big reason we jump up and down so much about the coding style is that its the one thing that ensures someone else can maintain and fix code that the author has abandoned, doesn't have time to fix or that needs access to specific hardware the authors may not have." Much of the rest of the thread was less friendly, leaving the question of merging Reiser4 into the mainline kernel still up in the air.
From: Hans Reiser [email blocked]
To: Andrew Morton [email blocked], Linus Torvalds [email blocked]
Subject: I request inclusion of reiser4 in the mainline kernel
Date: Fri, 16 Sep 2005 10:05:08 -0700
All objections have now been addressed so far as I can discern.
The VFS layering issue was addressed after 2 months of recoding.
The undesired type safe lists were removed after ~ a man week of coding.
Cosmetic issues regarding line length, etc., were addressed.
Numerous ~ one line changes were made that I will not address here.
The assertions were left in, with akpm's ok.
Pseudo files were removed.
dependency on !4k stacks was removed and stack usage was fixed.
reiser4_drop_inode was removed.
our div64_32 was replaced with the linux one
I request that reiser4 be included. Technically, we submitted 9 months
before the deadline for 2.6.14, though I am sure the point will be
argued. We would have submitted our feedback fixes on monday but we
lost the type safe lists argument over the weekend before monday, so it
delayed us.
There have been no bug reports concerning the new code.
If we get lucky, we might also have a compression plugin working by the
time 2.6.14 ships, it just needs some mmap fixes to work. Then the
benchmarks will be truly excessive..... even after we rewrite them
because they currently generate files that compress too well to be
realistic.....
:)
Thanks to all for your kind suggestions of improvements to our work, and
the time you invested in providing us with feedback. It will be easier
to use meta-. to browse our code now that the type safe lists are gone,
etc., etc.
Hans
From: Christoph Hellwig [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Fri, 16 Sep 2005 18:15:09 +0100
On Fri, Sep 16, 2005 at 10:05:08AM -0700, Hans Reiser wrote:
> All objections have now been addressed so far as I can discern.
>
> The VFS layering issue was addressed after 2 months of recoding.
>
> The undesired type safe lists were removed after ~ a man week of coding.
>
> Cosmetic issues regarding line length, etc., were addressed.
>
> Numerous ~ one line changes were made that I will not address here.
>
> The assertions were left in, with akpm's ok.
>
> Pseudo files were removed.
>
> dependency on !4k stacks was removed and stack usage was fixed.
>
> reiser4_drop_inode was removed.
>
> our div64_32 was replaced with the linux one
You completely ignore my last review comments. And that was just the
errors sticking out from an half an error look. I'll do a deeper review,
but ocfs has a higher priority right now.
From: Christoph Hellwig [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Fri, 16 Sep 2005 18:40:28 +0100
more trivial review comments ontop of the previous one, after looking
at things:
- please never use list_for_each in new code but list_for_each_entry
- never use kernel_thread in new code but kthread_*
- do_sendfile duplicates the common sendfile code. why aren't you
using the generic code?
- there's tons of really useless assertation of the category
discussed in the last thread
- there's tons of deep pagecache messing in there. normally this
shouldn't be a filesystem, and if this breaks because of VM changes you'll
have to fix it, don't complain..
- you still do your plugin mess in ->readpage. honsetly could you
please explain why mpage_readpage{,s} don't work for you?
- (issues with the read/write path already addresses in the previous thread)
- looking at ->d_count in ->release is wrong
- still has security plugin stuff that duplicates LSM
- why do underlying attributes change when VFS inode doesn't change?
if not please rip out most of getattr_common
- link_common S_ISDIR doesn't make sense, VFS takes care of it
- please use the generic_readlink infrastructure
additinoal comment is that the code is very messy, very different
from normal kernel style, full of indirections and thus hard to read.
real review will take some time.
From: Hans Reiser [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Fri, 16 Sep 2005 12:39:48 -0700
Christoph Hellwig wrote:
>additinoal comment is that the code is very messy, very different
>from normal kernel style, full of indirections and thus hard to read.
>
Most of my customers remark that Namesys code is head and shoulders
above the rest of the kernel code. So yes, it is different. In
particular, they cite the XFS code as being so incredibly hard to read
that its unreadability is worth hundreds of thousands of dollars in
license fees for me. That's cash received, from persons who read it
all, not commentary made idly.
May I suggest that you work on the XFS code instead? Surely with all of
this energy you have, you could improve XFS a lot before it gets
accepted into the kernel.
As for the indirections, if you figure out how to make VFS indirections
easy to follow, the same technique should be applicable to Reiser4, and
I will be happy to fix it.
Hans
(Note for the record: I actually think XFS acceptance was delayed too
long, and I think that XFS is a great filesystem, but a rhetorical point
needed to be made......)
From: Kyle Moffett [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Fri, 16 Sep 2005 15:52:45 -0400
[CC list trimmed to relevant people, no need to spam Linus' and
Andrew's mailboxes, they have enough to do as it is]
On Sep 16, 2005, at 15:39:48, Hans Reiser wrote:
> Christoph Hellwig wrote:
>> additinoal comment is that the code is very messy, very different
>> from normal kernel style, full of indirections and thus hard to read.
>
> Most of my customers remark that Namesys code is head and shoulders
> above the rest of the kernel code. So yes, it is different.
And yet thousands and thousands of people, businesses, etc, say that
the Linux kernel code is miles above all the commercial software out
there. Please leave the worthless rhetoric out of a technical
discussion. The issue stands that in many ways the Reiser4 code does
not exactly follow Documentation/CodingStyle and does not match most
of the rest of the kernel, making it hard to read for other kernel
developers. If you were just doing this forever as an external
kernel patch, nobody would give a damn. On the other hand, you're
trying to get it included in the upstream kernel, which means that
those same "other kernel developers" for whom it is hard to read may
be expected to maintain it until the end of time. Given this, it
seems perfectly reasonable to ask that it be cleaned up.
> In particular, they cite the XFS code as being so incredibly hard
> to read that its unreadability is worth hundreds of thousands of
> dollars in license fees for me.
How does XFS have _anything_ to do with Reiser4? A technical
discussion is no place for political pissing contest.
> [more useless posturing snipped]
> As for the indirections, if you figure out how to make VFS
> indirections easy to follow, the same technique should be
> applicable to Reiser4, and I will be happy to fix it.
That's not his responsibility, it's _yours_. If you want your stuff
included in the the kernel, you need to make sure it is sufficiently
acceptable. Besides, this is just one complaint of the many he
made. This may not be particularly solvable, but there are a number
of other points he made that you guys need to try to resolve.
> (Note for the record: I actually think XFS acceptance was delayed
> too long, and I think that XFS is a great filesystem, but a
> rhetorical point needed to be made......)
See above. Rhetoric has little or no place here. Such comments are
why Reiser4 typically triggers massive flamewars when it is mentioned
on the LKML.
Cheers,
Kyle Moffett
--
Somone asked me why I work on this free (http://www.fsf.org/
philosophy/) software stuff and not get a real job. Charles Shultz
had the best answer:
"Why do musicians compose symphonies and poets write poems? They do
it because life wouldn't have any meaning for them if they didn't.
That's why I draw cartoons. It's my life."
-- Charles Shultz
From: Denis Vlasenko [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Sat, 17 Sep 2005 13:51:57 +0300
On Friday 16 September 2005 22:52, Kyle Moffett wrote:
> [CC list trimmed to relevant people, no need to spam Linus' and
> Andrew's mailboxes, they have enough to do as it is]
>
> On Sep 16, 2005, at 15:39:48, Hans Reiser wrote:
> > Christoph Hellwig wrote:
> >> additinoal comment is that the code is very messy, very different
> >> from normal kernel style, full of indirections and thus hard to read.
> >
> > Most of my customers remark that Namesys code is head and shoulders
> > above the rest of the kernel code. So yes, it is different.
>
> And yet thousands and thousands of people, businesses, etc, say that
> the Linux kernel code is miles above all the commercial software out
> there. Please leave the worthless rhetoric out of a technical
> discussion. The issue stands that in many ways the Reiser4 code does
> not exactly follow Documentation/CodingStyle and does not match most
> of the rest of the kernel, making it hard to read for other kernel
> developers. If you were just doing this forever as an external
> kernel patch, nobody would give a damn. On the other hand, you're
> trying to get it included in the upstream kernel, which means that
> those same "other kernel developers" for whom it is hard to read may
> be expected to maintain it until the end of time. Given this, it
> seems perfectly reasonable to ask that it be cleaned up.
I think it makes sense to supply examples from reiser4 code
which you want to be changed. "It's ugly" is not specific enough.
--
vda
From: Hans Reiser [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Sun, 18 Sep 2005 22:01:41 -0700
Denis Vlasenko wrote:
>
>>And yet thousands and thousands of people, businesses, etc, say that
>>the Linux kernel code is miles above all the commercial software out
>>there.
>>
Not the commercial software I have worked with. IBM code, government
procured code, both are much more readable code than Linux Kernel
standards. I am sure there is no shortage of bad IBM code and bad
government code, but my personal experiences were that it was much
better commented. Your statement sounds like something you want to
believe.
That all said, the kernel code is getting better..... if the rest of
the kernel was as well commented as akpm's code I would not be
complaining at all.
From: Christoph Hellwig [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Sat, 17 Sep 2005 10:22:47 +0100
On Fri, Sep 16, 2005 at 12:39:48PM -0700, Hans Reiser wrote:
> Christoph Hellwig wrote:
>
> >additinoal comment is that the code is very messy, very different
> >from normal kernel style, full of indirections and thus hard to read.
> >
>
> Most of my customers remark that Namesys code is head and shoulders
> above the rest of the kernel code. So yes, it is different. In
> particular, they cite the XFS code as being so incredibly hard to read
> that its unreadability is worth hundreds of thousands of dollars in
> license fees for me. That's cash received, from persons who read it
> all, not commentary made idly.
It's very different from kernel style, and it's hard to read for us kernel
developers. And yes, I don't think XFS is the most easy to read code either,
quite contrary. But it's at least half a magnitude less bad than reiser4
code..
From: Denis Vlasenko [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Sat, 17 Sep 2005 13:56:14 +0300
On Saturday 17 September 2005 12:22, Christoph Hellwig wrote:
> On Fri, Sep 16, 2005 at 12:39:48PM -0700, Hans Reiser wrote:
> > Christoph Hellwig wrote:
> >
> > >additinoal comment is that the code is very messy, very different
> > >from normal kernel style, full of indirections and thus hard to read.
> > >
> >
> > Most of my customers remark that Namesys code is head and shoulders
> > above the rest of the kernel code. So yes, it is different. In
> > particular, they cite the XFS code as being so incredibly hard to read
> > that its unreadability is worth hundreds of thousands of dollars in
> > license fees for me. That's cash received, from persons who read it
> > all, not commentary made idly.
>
> It's very different from kernel style, and it's hard to read for us kernel
> developers. And yes, I don't think XFS is the most easy to read code either,
> quite contrary. But it's at least half a magnitude less bad than reiser4
> code..
At least reiser4 is smaller. IIRC xfs is older than reiser4 and had more time
to optimize code size, but:
reiser4 2557872 bytes
xfs 3306782 bytes
--
vda
From: Denis Vlasenko [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Sat, 17 Sep 2005 14:15:50 +0300
> At least reiser4 is smaller. IIRC xfs is older than reiser4 and had more time
> to optimize code size, but:
>
> reiser4 2557872 bytes
> xfs 3306782 bytes
And modules sizes:
reiser4.ko 442012 bytes
xfs.ko 494337 bytes
--
vda
From: Chris White [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Sun, 18 Sep 2005 09:34:45 +0900
CC-List trimmed
On Saturday 17 September 2005 20:15, Denis Vlasenko wrote:
> > At least reiser4 is smaller. IIRC xfs is older than reiser4 and had more
> > time to optimize code size, but:
> >
> > reiser4 2557872 bytes
> > xfs 3306782 bytes
>
> And modules sizes:
>
> reiser4.ko 442012 bytes
> xfs.ko 494337 bytes
All this is fine and dandy, but saying "My code is better than yours!!" still
doesn't solve the issue this thread hopes to achieve, that being "I'd like to
get reiser4 into the kernel". There seems to be a lot of (historical?)
tension present here, but all that seems to be doing is making things worse.
PLEASE keep this thing a tad on par. Keeping this up is hurting everyone
more than helping. I wish I could say something as simple as "let's just be
friends", but that's saying a lot. I can say this though: this is open
source, and that means that our source is open, and we should be too.
Chris White
From: Denis Vlasenko [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Sun, 18 Sep 2005 13:21:23 +0300
On Sunday 18 September 2005 03:34, Chris White wrote:
> CC-List trimmed
>
> On Saturday 17 September 2005 20:15, Denis Vlasenko wrote:
> > > At least reiser4 is smaller. IIRC xfs is older than reiser4 and had more
> > > time to optimize code size, but:
> > >
> > > reiser4 2557872 bytes
> > > xfs 3306782 bytes
> >
> > And modules sizes:
> >
> > reiser4.ko 442012 bytes
> > xfs.ko 494337 bytes
>
> All this is fine and dandy, but saying "My code is better than yours!!" still
> doesn't solve the issue this thread hopes to achieve, that being "I'd like to
> get reiser4 into the kernel". There seems to be a lot of (historical?)
> tension present here, but all that seems to be doing is making things worse.
> PLEASE keep this thing a tad on par. Keeping this up is hurting everyone
> more than helping. I wish I could say something as simple as "let's just be
> friends", but that's saying a lot. I can say this though: this is open
> source, and that means that our source is open, and we should be too.
I am trying to say that I think that Hans is being treated a bit unfairly.
His fs is new and has fairly complex on-disk structure and complex journalling
machinery, yet his source and object code is smaller than xfs which already
is accepted. This is no easy feat I guess.
Maybe xfs shouldn't be accepted too, this may be an answer.
Let's look at the code. Hans' code is not _that_ awful. Yet people
(not all of them, but some) do not point to specific things which they
want to be fixed/improved. I see blanket arguments like "your code is hard
to read". Well. Maybe spend a minute on what exactly is hard to read,
or do we require Hans to be able to read minds from the distance?
This is it. I do not say "accept reiser4 NOW", I am saying "give Hans
good code review".
--
vda
From: Christoph Hellwig [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Sun, 18 Sep 2005 11:26:58 +0100
On Sun, Sep 18, 2005 at 01:21:23PM +0300, Denis Vlasenko wrote:
> This is it. I do not say "accept reiser4 NOW", I am saying "give Hans
> good code review".
After he did his basic homework. Note that reviewing hans code is probably
at the very end of everyones todo list because every critizm of his code
starts a huge flamewar where hans tries to attack everyone not on his
party line personally.
I've said I'm gonna do a proper review after he has done the basic homework,
which he seems to have half-done now at least. Right now he hasn't finished
that and there's much more exciting filesystems like ocfs2 around that
are much easier to read and actually have developers that you can have
a reasonable conversation with. (and that unlike hans actually try to
improve core code where it makes sense for them)
From: michael chang [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Sun, 18 Sep 2005 13:22:27 -0400
On 9/18/05, Christoph Hellwig [email blocked] wrote:
> On Sun, Sep 18, 2005 at 01:21:23PM +0300, Denis Vlasenko wrote:
> > This is it. I do not say "accept reiser4 NOW", I am saying "give Hans
> > good code review".
>
> After he did his basic homework. Note that reviewing hans code is probably
> at the very end of everyones todo list because every critizm of his code
> starts a huge flamewar where hans tries to attack everyone not on his
> party line personally.
>
> I've said I'm gonna do a proper review after he has done the basic homework,
> which he seems to have half-done now at least. Right now he hasn't finished
Explain to us all what is this "basic homework" of which you speak.
> that and there's much more exciting filesystems like ocfs2 around that
This is exciting to... whom? The only thing that appears remotely
interesting about it is that it's made by Oracle and apparently is
supposed to be geared toward parallel server whatsits. This might be
helpful to corporations, but seems senseless toward many consumers.
(I'm assuming there's still at least one consumer left who still uses
Linux.)
> are much easier to read and actually have developers that you can have
> a reasonable conversation with. (and that unlike hans actually try to
Is that Hans' fault, or the fault of your lot? Why can't we all just get along?
Give Hans a chance; and please try to understand, even if he's hard to
work with. Discriminate him because he's not a developer you can talk
with, and I believe that's like discriminating a guy in a wheelchair
because he can't run with you when you jog in the morning.
> improve core code where it makes sense for them)
Not everyone has the same "common sense" that you do. Explain, fully,
with reasoning, and reproducable back-up statistics on common
hardware, what code is wrong, and what must be written instead. We'd
like to be efficient, and it's not being efficient to play a guessing
game with us. If you don't have the time to review, then please hold
off on replying until you have a through review of at least part of
the code.
Unless you object fully to one particular, fixable thing that isn't
the core of Reiser4, it'd be nice for you to wait on replying --
vagueness is not helpful to development in any way. Are we supposed
to be the million monkeys randomly typing on a million typewriters
waiting for someone to give you code that you like, one in a million
years?
Also, let's say that Reiser4 doesn't get into the kernel, as maybe XFS
or ext2 or ext3 had never gotten into the kernel. How would their
development be now as opposed to how we see it, when they have gotten
into the kernel? I don't see anything wrong with the idea of letting
what seems a mostly mature FS into the kernel; that is how most bugs
are found in the first place. Of course, there is nothing wrong with
putting huge warnings on the FS; I'd recommend them, considering that
some people are having funky problems with the patch.
I'm willing to go compare Reiser4 to ext2/3 as like H.264 to Mpeg-2.
Indeed, H.264 crashes some computers, similar to Reiser4 might crash
some machines, but this is merely because Reiser4 explores new
concepts, meaning it may require hardyier hardware than ext2/3, as
H.264 requries hardier hardware than Mpeg-2. I believe that the
concept is the same. (And all the same, media companies are embracing
H.264 - why can't you guys embrace this new idea also?) Change is
hard. Besides, if Reiser4 is truely that flawed, we will see in a few
releases, and then afterwards if it's proven to everyone that Reiser4
is completely unrepairable and hopeless, it can then be ditched and
thrown into the trash.
My apologies for my rudeness, but I am rather fond of the developments
in Reiser4, and would love to see it in the kernel. I am fond of
Linux too, and the work that you guys do, and it would dissapoint me
sorrily if Reiser4 never makes it into the Linux kernel. Feel free to
say I'm a tad biased; I will say now that I probably have much less
merit in the field than you guys do.
--
~Mike
- Just my two cents
- No man is an island, and no man is unable.
From: Horst von Brand [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Sun, 18 Sep 2005 16:04:19 -0400
michael chang [email blocked] wrote:
> On 9/18/05, Christoph Hellwig [email blocked] wrote:
> > On Sun, Sep 18, 2005 at 01:21:23PM +0300, Denis Vlasenko wrote:
> > > This is it. I do not say "accept reiser4 NOW", I am saying "give Hans
> > > good code review".
> > After he did his basic homework. Note that reviewing hans code is probably
> > at the very end of everyones todo list because every critizm of his code
> > starts a huge flamewar where hans tries to attack everyone not on his
> > party line personally.
> > I've said I'm gonna do a proper review after he has done the basic
> > homework, which he seems to have half-done now at least. Right now he
> > hasn't finished
> Explain to us all what is this "basic homework" of which you speak.
The required cleanups have been posted (in outline at least), several
times, by unrelated people.
> > that and there's much more exciting filesystems like ocfs2 around that
> This is exciting to... whom?
To Cristoph, obviously. You should thank him for doing the (hard, boring,
thankless) work of reviewing code for free. Even if it isn't yours. As he
is doing it as community service, I wouldn't dare blame him for picking
whatever he likes most, for whatever reasons.
> The only thing that appears remotely
> interesting about it is that it's made by Oracle and apparently is
> supposed to be geared toward parallel server whatsits. This might be
> helpful to corporations, but seems senseless toward many consumers.
Cristoph finds it interesting, that should be enough for everybody not
paying him for doing the work.
> (I'm assuming there's still at least one consumer left who still uses
> Linux.)
Count me in. That doesn't mean I agree with ReiserFS' goals...
> > are much easier to read and actually have developers that you can have
> > a reasonable conversation with. (and that unlike hans actually try to
> Is that Hans' fault, or the fault of your lot? Why can't we all just get
> along?
Hans is one person, and he has managed to alienate a most of the LKML
bunch. Sure, there are very abrasive people here, but there are plenty that
are extremely helpful to newbies that /really/ want to learn how to do
things right.
> Give Hans a chance; and please try to understand, even if he's hard to
> work with. Discriminate him because he's not a developer you can talk
> with, and I believe that's like discriminating a guy in a wheelchair
> because he can't run with you when you jog in the morning.
Please consider that most people here are volunteers, they owe nobody
nothing. Quite the contrary: if somebody wants to unload their code (and
its future maintenance) on the kernel crew, they are in /great/ debt if it
gets accepted.
> > improve core code where it makes sense for them)
> Not everyone has the same "common sense" that you do. Explain, fully,
> with reasoning, and reproducable back-up statistics on common hardware,
> what code is wrong, and what must be written instead. We'd like to be
> efficient, and it's not being efficient to play a guessing game with us.
> If you don't have the time to review, then please hold off on replying
> until you have a through review of at least part of the code.
Can't do. It is mostly an artistic sense of taste.
> Unless you object fully to one particular, fixable thing that isn't the
> core of Reiser4, it'd be nice for you to wait on replying -- vagueness is
> not helpful to development in any way. Are we supposed to be the million
> monkeys randomly typing on a million typewriters waiting for someone to
> give you code that you like, one in a million years?
You are the ones that want to benefit from having your code in the kernel.
You evaluate if the (standard!) cycle of "Code, propose, get rejected, fix,
repropose, ... until finally accepted" works for you or just isn't worth
the bother.
> Also, let's say that Reiser4 doesn't get into the kernel, as maybe XFS
> or ext2 or ext3 had never gotten into the kernel. How would their
> development be now as opposed to how we see it, when they have gotten
> into the kernel? I don't see anything wrong with the idea of letting
> what seems a mostly mature FS into the kernel; that is how most bugs
> are found in the first place. Of course, there is nothing wrong with
> putting huge warnings on the FS; I'd recommend them, considering that
> some people are having funky problems with the patch.
Just unloading some untested code on unsuspecting, innocent users is not
very nice, is it?
> I'm willing to go compare Reiser4 to ext2/3 as like H.264 to Mpeg-2.
> Indeed, H.264 crashes some computers, similar to Reiser4 might crash
> some machines, but this is merely because Reiser4 explores new
> concepts, meaning it may require hardyier hardware than ext2/3, as
> H.264 requries hardier hardware than Mpeg-2.
Either one crashing the machine is unacceptable (in principle at least). A
filesystem is so central to "everything is a file" that filesystem problems
are doubly unacceptable. There are lots of reports of ReiserFS 3
filesystems completely destroyed by minor hardware flakiness. And that has
/never/ been fixed, as the developers just went off to do the "next cool
thing". That history weighs against ReiserFS, heavily.
> I believe that the
> concept is the same. (And all the same, media companies are embracing
> H.264 - why can't you guys embrace this new idea also?) Change is
> hard. Besides, if Reiser4 is truely that flawed, we will see in a few
> releases, and then afterwards if it's proven to everyone that Reiser4
> is completely unrepairable and hopeless, it can then be ditched and
> thrown into the trash.
It is cheaper for everybody involved to throw it in the thrash /before/
lots of people are dependent on it, and throw it out then. Just consider
the pain caused by including (and now ditching) devfs.
> My apologies for my rudeness, but I am rather fond of the developments
> in Reiser4, and would love to see it in the kernel. I am fond of
> Linux too, and the work that you guys do, and it would dissapoint me
> sorrily if Reiser4 never makes it into the Linux kernel. Feel free to
> say I'm a tad biased; I will say now that I probably have much less
> merit in the field than you guys do.
All this has been discussed in BIGNUM flamewars already, neither your nor
my post helps a bit in either way (except in fanning the flames), so please
let's drop this.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
From: Hans Reiser [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Sun, 18 Sep 2005 22:44:04 -0700
Horst von Brand wrote:
>
>>>that and there's much more exciting filesystems like ocfs2 around that
>>>
>>>
>
>
>
>>This is exciting to... whom?
>>
>>
>
>To Cristoph, obviously. You should thank him for doing the (hard, boring,
>thankless) work of reviewing code for free. Even if it isn't yours. As he
>is doing it as community service, I wouldn't dare blame him for picking
>whatever he likes most, for whatever reasons.
>
>
Well maybe he should just go away then and save his and our time.
Reiser4 works just fine without Christoph. Users are happy with it.
None of them have asked for his help. I don't consider Christoph to be
qualified to work on our filesystem. I would not hire him if he applied
--- he is not capable of innovative work.
Reiser4 is far from perfect, but it is ready for more users.
>
>>Is that Hans' fault, or the fault of your lot? Why can't we all just get
>>along?
>>
>>
>
>Hans is one person, and he has managed to alienate a most of the LKML
>bunch. Sure, there are very abrasive people here, but there are plenty that
>are extremely helpful to newbies that /really/ want to learn how to do
>things right.
>
>
Yes, but the helpful ones have nothing to do with VFS. Linux has lost
filesystem developers because of the VFS team, developers who I can tell
you were very very gifted DARPA researchers who decided to work on BSD
because they had too much dignity to develop a filesystem for Linux. I
assure you that no one on the VFS team is as bright or capable as one of
the fellows I know of that they abused away.
>>If you don't have the time to review, then please hold off on replying
>>until you have a through review of at least part of the code.
>>
>>
>
>Can't do. It is mostly an artistic sense of taste.
>
>
Yes, which is why people who have not written a serious filesystem
should not instruct those who have written the measurably fastest one.
> Also, let's say that Reiser4 doesn't get into the kernel, as maybe XFS
>
>>or ext2 or ext3 had never gotten into the kernel. How would their
>>development be now as opposed to how we see it, when they have gotten
>>into the kernel? I don't see anything wrong with the idea of letting
>>what seems a mostly mature FS into the kernel; that is how most bugs
>>are found in the first place. Of course, there is nothing wrong with
>>putting huge warnings on the FS; I'd recommend them, considering that
>>some people are having funky problems with the patch.
>>
>>
>
>Just unloading some untested code on unsuspecting, innocent users is not
>very nice, is it?
>
>
Christoph is not testing. We have tested, our mailing list has tested.....
> There are lots of reports of ReiserFS 3
>
>filesystems completely destroyed by minor hardware flakiness. And that has
>/never/ been fixed, as the developers just went off to do the "next cool
>thing". That history weighs against ReiserFS, heavily.
>
>
We are supposed to write a filesystem so that overheating CPUs do not
make it crash?
Prejudice is a very simple phenomenom. When either ext3 or ReiserFS V3
crash it is almost always due to bad hardware. Prejudice is the process
of remembering that one filesystem crashed due to bad hardware and not
remembering that the other one crashed.
It is remarkably simple how it works: people who use Reiser4 want it in,
people who use ext3 and don't want to have a choice of something else
don't want it in. That was true of V3, and it is true of V4. My point
of course is that those who have used V4 know more about it than those
who haven't......
I think Alan Cox is the only poster who has no intention of using
Reiser4 but said at one point that he thinks it should go in.
V3 is obsoleted by V4 in every way. V3 is old code that should be
marked as deprecated as soon as V4 has passed mass testing. V4 is far
superior in its coding style also. Having V3 in and V4 out is at this
point just stupid.
This whole thing reminds me of an IBMer who told me that he thought that
IBM lost to MS because they called OS/2 by a name other than DOS. The
sad thing is he was probably right.
V4, as it is today, is as much superior to V3 as OS/2 was to DOS. Any
distro or user who would stay with V3 for new installs once we have
passed mass testing is nuts. We need the mass testing.
Hans
From: Alan Cox [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Mon, 19 Sep 2005 11:51:21 +0100
On Sul, 2005-09-18 at 22:44 -0700, Hans Reiser wrote:
> We are supposed to write a filesystem so that overheating CPUs do not
> make it crash?
The reverse - and before you lose data.
> I think Alan Cox is the only poster who has no intention of using
> Reiser4 but said at one point that he thinks it should go in.
If its clean enough then yes, like any other fs. Until then no.
From: Alan Cox [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Sun, 18 Sep 2005 22:38:44 +0100
On Sul, 2005-09-18 at 13:22 -0400, michael chang wrote:
> This is exciting to... whom? The only thing that appears remotely
> interesting about it is that it's made by Oracle and apparently is
> supposed to be geared toward parallel server whatsits.
Which no current included fs supports. And parallel file systems btw get
exciting for everyone once you have virtualisation.
> Is that Hans' fault, or the fault of your lot? Why can't we all just get along?
Insufficient drugs ;) ?
> work with. Discriminate him because he's not a developer you can talk
> with, and I believe that's like discriminating a guy in a wheelchair
> because he can't run with you when you jog in the morning.
Hans can learn to work with people, most folks in wheelchairs cannot
take lessons and walk. Many of them have tried months of physiotherapy.
to learn to walk again. I think your comparison is insulting to a lot of
the disabled.
> Also, let's say that Reiser4 doesn't get into the kernel, as maybe XFS
> or ext2 or ext3 had never gotten into the kernel. How would their
Linus refused ext3 initially. It went in because it had a userbase,
vendors shipping it and reliable clean code. Saying "no" a lot is really
rather important to keeping the kernel maintainable. I regularly meet
cases we should have said "no" a lot louder 8)
> I'm willing to go compare Reiser4 to ext2/3 as like H.264 to Mpeg-2.
> Indeed, H.264 crashes some computers, similar to Reiser4 might crash
> some machines, but this is merely because Reiser4 explores new
It doesn't matter if reiser4 causes crashes. It matters that people can
fix them, that they are actively fixed and the code is maintainable. It
will have bugs, all complex code has bugs. Hans team have demonstrated
the ability to fix some of those bugs fast, but we also all remember
what happened with reiser3 later on despite early fast fixing.
One big reason we jump up and down so much about the coding style is
that its the one thing that ensures someone else can maintain and fix
code that the author has abandoned, doesn't have time to fix or that
needs access to specific hardware the authors may not have.
Alan
From: Hans Reiser [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Sun, 18 Sep 2005 22:07:18 -0700
Alan Cox wrote:
>
>It doesn't matter if reiser4 causes crashes. It matters that people can
>fix them, that they are actively fixed and the code is maintainable. It
>will have bugs, all complex code has bugs. Hans team have demonstrated
>the ability to fix some of those bugs fast, but we also all remember
>what happened with reiser3 later on despite early fast fixing.
>
>
What was that?
>One big reason we jump up and down so much about the coding style is
>that its the one thing that ensures someone else can maintain and fix
>code that the author has abandoned, doesn't have time to fix or that
>needs access to specific hardware the authors may not have.
>
So why is the code in the kernel so hard to read then?
Linux kernel code is getting better, and Andrew Morton's code is
especially good, but for the most part it's unnecessarily hard to read.
Look at the elevator code for instance. Ugh.
I differ in one major aspect from some. That is, the only coding style
requirement I have of those who work for me is that it must be easy to
read. That is because at every company I can remember where someone was
gungho about advocating that code be written in a specific defined
style, that someone was always the one with the least readable code.
I have a simple punishment for those who violate my requirement: I go
through the code line by line with them, which they always hate for some
reason, and help them comment and clarify it. 1-2 sessions of this, and
they usually change how they code so that they don't have to go through
it again with me.
Asking for readable code is not that different from asking for readable
novels: if you try to define what is required rather than teaching
instance by instance, you can only get in the way of the artist rather
than instructing.
That is why I just say "make it easy to read and I don't care how you do
that so long as it works."
From: Christoph Hellwig [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Mon, 19 Sep 2005 10:01:45 +0100
Thanks a lot for the groundless attacks, but I'm done.
I'll stop helping you to review stuff because it's just totally pointless,
you ignore most of the review anyway and start personal attacks.
Please find someone else to review your code for inclusion, that can stand
beeing attacked everytime they write an email. Before you should probably
fix up various bits I wrote up and especialy make sure to get rid of
all duplication of generic I/O code or explain in detail why you need it
and fix your own implementations.
And next time you request review request and inclusion please use nicer
words than 'I request inclusion'. There's no right to get code included
in the kernel tree, it's a honor.
From: Andrew Morton [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Mon, 19 Sep 2005 02:21:53 -0700
Christoph Hellwig [email blocked] wrote:
>
> Before you should probably
> fix up various bits I wrote up and especialy make sure to get rid of
> all duplication of generic I/O code or explain in detail why you need it
> and fix your own implementations.
Yup, thanks. I've made a record of your comments in the changelog for
-mm's reiser4-only.patch.
From: Alan Cox [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Mon, 19 Sep 2005 11:43:36 +0100
On Sul, 2005-09-18 at 22:07 -0700, Hans Reiser wrote:
> >the ability to fix some of those bugs fast, but we also all remember
> >what happened with reiser3 later on despite early fast fixing.
> >
> >
> What was that?
Jeff Mahoney added file attributes to reiserfs3, you whined and pointed
people at the yet to be released reiserfs4. Someone fixed the 4K stack
on reiserfs3, you whined. Chris Mason added other fixes like
data=journal support to get some kind of journal feature parity with
ext3, you complained and ask it not to be added.
> That is why I just say "make it easy to read and I don't care how you do
> that so long as it works."
Perhaps you do. The kernel follows a coding style. It isn't my coding
style but like everyone else except you I try and follow it.
Alan
Happy Shiny Kernel Developers
Why can't we all just get along? I'd love to see Reiser4 in the mainline kernel, and I'd love to see many of its principals get picked up by other filesystems ... but frankly it appears interpersonal issues are going to keep that from happening.
If kernel developers were diplomats, we'd all be nuked by now. Thank God they're great hackers. ;-)
Here's a revealing quote from
Here's a revealing quote from an osnews.com interview with the FreeBSD Core team:
I believe the Linux kernel maintainers need someone to play mediator and smooth ruffled feathers before they get to this stage.
"I believe the Linux kernel m
"I believe the Linux kernel maintainers need someone to play mediator and smooth ruffled feathers before they get to this stage."
In many ways that's Linus's job. His tactic tends to be "ignore personal issues as much as possible, make the best possible technical decision." The side effect of that is you can generally trust that Linus's decisions aren't personal, so what gets in and what doesn't tends not to throw anyone but the most soft skinned off the deep end.
It's worth noting that Hans Reiser is a cocky, abrasive man. Abrasive is a personality trait, and he isn't the only cocky one in kernel development (Linus, for example). The fact that Reiser4 is still being considered shows that the kernel is doing quite well, as far as personal issues go
Abrasive? He's an absolute as
Abrasive? He's an absolute asshole in this thread. Not one bit of civil text and certainly no respect or common courtesy. Most, if not quite all, responses are direct attacks and have no connection to the matter at hand. Name any classic fallacy and he's tried to use it as reason.
I wouldn't blame anyone for refusing communication. Anyone coming across like that would have ended in /ignore or kill file *very* fast if I'd come across the message in something I read.
Not especially "in this thread"
As far as I remember, all his emails are like this..
Even for the inclusion of the original ReiserFS, he was like this.
As for the original ReiserFS, some would count it as a success, me I'm a bit wary about it: I've seen too often filesystem corruption with it, but that's just 'point' data, I've no meaningful statistic to prove my point.
personal comments
Do you know Hans personally?
statements like "Hans Reiser is a cocky, abrasive man" is not very diplomatic especially as you talk about "smoothing ruffled feathers".
It is also not really true, as far as someone who actually talked to him several times in person can tell.
People can be completely diff
People can be completely different in person and when communicating through Internet Chat or E-mail. Someone who's soft-spoken and diplomatic in person can be abrasive and unpleasant in e-mail. (I'm not speaking of Reiser specifically here-- I haven't had contact with him either way)
Yeah, just merge it!
I'd love to try it!
Try -mm.
Try -mm.
I know, but
hmm, yeah, but -mm is a little bit too experimentally for me...
And _backporting_ reiser4 takes a lot of time.
Try 2.6.14-rc1-mm1 I couldn't
Try 2.6.14-rc1-mm1 I couldn't crash it. See my klive uptime Klive
host: 6ce68650 :)
jabadabadu
Ok, I gave it a try. It really seems to be stable for me.
Now, I only need my 250 GB Driver ...
Hit'em with a bravery stick! Reiser4 just plain works for me.
Faster, better less latency. Merge it now.
Then download the patches and
Then download the patches and give it a try, there's nothing stopping you from doing that.
Try SuSE 10.0
Try SuSE 10.0 ..
I think Hans should not worry about what others says in kernel mainteners .. contact major distributors . Like OpenSuSE, Mandriva and it as an option .. who wants to try it will try it .. most people do not use stock kernel in any way ... :)
Undiplomatic
It seems like going through other routes, not directly through the kernel developers, might be even more of a diplomatic mistake. I have been eagerly awaiting the inclusion of Reiser4 into the main kernel; I'm not much for using large patches such as Reiser4 to deal with the most important information on my computer. Anything more that Hans Reiser can do to annoy the main kernel developers would naturally worse for my goal.
Hans has certainly sold the c
Hans has certainly sold the case that he is a cutting-edge filesystem developer to the masses. I personally think folks here think too highly of him.
If you think that reiserfs is really a badly-designed (from viewpoint of kernel: duplication of apis), complex filesystem with similar performance to the others, you may end up seeing this more in the perspective and the complaints.
According to benchmarks I've seen reiser4 is both faster and slower than the competition. It depends on the type of test. For the normal user, I don't think he can even tell whether he's using ext2, 3, jfs, xfs, or reiserfs. So what's the point?
The exciting part is the new
The exciting part is the new features which apparently won't ever be accepted by the kernel crew (metadata pseudofiles, etc). So, yeah, the neutered version of reiser4 that might actually get merged won't be very interesting at all.
As far as coding style and design go, the Linux kernel is basically an advertising platform as far as Hans is concerned. It is the place where his filesystems can go that guarantees high visibility and usage. If you're a very ambitious filesystem designer (you might even say "fame seeking"), what more could you ask for? It's obvious that he cares very little for the design of the kernel as a whole, provided it provides the necessary facilities for his filesystems to work.
I believe you nailed it to th
I believe you nailed it to the head.
Fantastic!
>If kernel developers were diplomats, we'd all be nuked by now. Thank they're great hackers. ;-)
Really fantastic, I'll use in my sig. :)))))))))
Included! (nearly)
Semms like this guy (Reiser-bashing Christoph Hellwig) has stopped his reiser bashing (he is calling it "review"):
"Thanks a lot for the roundless attacks, but I'm done. I'll stop helping you to review stuff because it's just totally pointless, you ignore most of the review anyway and start personal attacks."
Maybe all Linux users are able to test Reiser4 really soon. Today only Suse and Gentoo users are able to create Reiser4 filesystems without any patching of the kernel.
Only SUSE and Gentoo?
Maybe all Linux users are able to test Reiser4 really soon. Today only Suse and Gentoo users are able to create Reiser4 filesystems without any patching of the kernel.
I have selected ResierFS as the filing system while installing the following distros:
Fedor Core 2 and 3
Knoppix
Kannotix
Mepis 3.3
LibraNet 2.8
Xandros
Ubuntu 5.4
and several others.
Reiser3 or Reiser4?
Reiser3 or Reiser4?
He's clearly talking about 3.
He's clearly talking about 3. He obviously doesn't understand what he's commenting on.
They are not the same
ReiserFS (the FS you have used) and Reiser4 are two different things. ReiserFS (AKA Reiser v3) has been in the kernel for a long time. Reiser4 (AKA Reiser v4) is not in the standard kernel.
After comments like: "If y
After comments like:
"If you were as well suited to doing code reviews as I am, you would have written a faster file system yourself."
And:
"I could get what you do from hiring a college junior, and if it was a good university I'd probably learn more from that junior in college than from you."
I can't imagine why Christoph would want to help Hans get his fs into the kernel, I'm actually surprised he lasted as long as he did. He stopped the review because as he got tired of Hans' shit and the flood of email from people without a clue screaming "It's cool and fast, just merge it already!!!". I would be happy to see reiser4 pushed back to 2.6.20 or later just to spite Hans at this point.
I would be happy to see reise
I would be happy to see reiser4 pushed back to 2.6.20 or later just to spite Hans at this point.
It is people with perspectives such as this that inhibit improvements in technology, society, and evolution.
It is people with perspective
Hans brings it upon himself, he's a dick to those that are trying to help him just because he can't accept any criticism about his baby. It would be a good thing for his ego to be taken down a few notches, maybe then the same thing won't happen with reiser5.
No, the real problems are soc
No, the real problems are social problems, and Hans is a prime example of an anti-social (I'm judging this only with regard to emails and mailing lists) person who thinks he's so far superior to the rest of the world that they should thank him for his condescending attitude and harshly abrasive personality.
If Hans wants his code in the kernel, he should adopt to kernel coding style and should learn to interact like other kernel contributors do. How many other people do you see who constantly resort to name-calling and unjustified personal attacks? Most of us grew out of this type of behavior some point at some point in our teenage years, and Hans needs to also.
The normal gentoo-sources ker
The normal gentoo-sources kernel does not include the reiser4 patches. Perhaps you're thinking of a more obscure non-standard kernel in the portage tree?
mm-sources is the only in-por
mm-sources is the only in-portage kernel that has reiser4, AFAIK. However, reiser4progs have been in the portage tree for quite some time now.
Distributions with Reiser4 Support
According to http://en.wikipedia.org/wiki/Comparison_of_Linux_distributions#Technical
Arch, Gentoo, Linspire and Suse have Reiser4 support.
The latest Mandriva has Reiser4 support also with its multimedia kernel.
The tools are in the reposito
The tools are in the repository and if mm-sources include Reiser4 that's fine. Still none of the kernels supported by Gentoo includes Reiser4.
debian also has reiser4. just
debian also has reiser4. just a simple kernel build command automatically installs the patch and adds reiser4.
Let him be that way
If he wants to be an ass, then let him! Don't include Reiser4! No one is going to suffer if it never goes mainline. "Yes! I want my filesystem to disappear all of the sudden!"
It's sad
"And next time you request review request and inclusion please use nicer words than 'I request inclusion'. There's no right to get code included in the kernel tree, it's a honor."
Christoph Hellwig, Mon, 19 Sep 2005 10:01:45 +0100, Message-Id 20050919090145.GA15607@infradead.org.
Christoph is right, yeah. He's such a good developer and without his contribution to the Linux kernel we'd surely miss some things. I simply don't understand why such a person is acting like a sixteen year old scripting kiddie, so self confident, so full of self esteem, so arrogant.
I follow LKML for years now. People always argue on technology and on how to put things right. Some of them do it like adults do, some not. Some are polite, some not.
I think Hans has put that in a very good way:
"What you are is someone who substitutes social connections for technical ability."
(Hans Reiser, Sun, 18 Sep 2005 22:16:11 -0700, Message-ID: 432E499B.7000003@namesys.com).
It's sad that some people act like hch does. He might be a genius, but does he really have to show that to people in THIS way?
Heh heh, s/hch/hans reiser.
Heh heh, s/hch/hans reiser. They're both behaving like children. If they could both focus on the code, it would have been merged long ago.
Compare!
Ok. Let's compare.
Not count of physical lines of source code. Not count of patches. And, not count of unfriendly, dismotivating and sometimes insulting LKML posts.
What kernel subsystems is hch the author of? (I mean subsystem, not patch). What complexity do these subsystems have? Which features?
vs.
What kernel subsystems is the Namesys crew author of? (I won't answer.) What complexity do these subsystems have? Which features?
Find an answer?
Compare?
Sun Tsu said:
In a certain village, there was a family of three brothers, all physicians. The oldest brother could cure any disease, even in a very late stage, and bring the sufferer back to health. His name was known for hundreds of miles. The second brother could diagnose any disease at its first symptom, and cure it immediately. His name was known in all the surrounding villages. Under the third brother's care, nobody ever became ill. His name was not known outside the house.
Which of the brothers was the greatest physician?
-
The only real issue here is that the code needs to be changed, but Hans Reiser is personally emotionally invested in it. His attachment blinds him to its faults. It's his baby. It's perfect. If you can't see how wonderful it is, you must be a fool. (Here I refer you to any good book on writing prose.)
It won't be fixed. Not because Hans won't fix it, but because he can't until he gives up the attachment. That's probably what is turning Christoph into such a jerk. He doesn't want to deal with that.
How can you expect Hans to "g
How can you expect Hans to "give up attachment" to something he invested his whole professional life (or possibly more) into? Can you expect a mother to give up attachment to her children? But at the same time, I don't think Has thinks it's perfect.
Hans is even saying it's not perfect
Anonymous wrote:
He thinks it needs mass testing to get it better, but I agree that nobody would give up something in which you spend do much time in.
Hans wrote:
Christoph Hellwig
I've been following LKML for many years and watched all the major flame wars, and the thing I can conclude is that Christoph Hellwig has been always acting like a PITA when it comes to raiserfs and Hans.
Christoph Hellwig is certainly capable of what he is doing on the kernel, and many of his comments do have merits, but he is really a rude person (not just to Hans). He acts as if he were doing a charity work to say yes to including other's work, and feels good for himeslef for having such a power (which by the way he doesn't have).
Some kernel developers are really arrogant when reviewing others' work, and forget the very fact that we also should be grateful to others who contribute GPL code to the kernel. The community should create an atmosphere to make this contribution a pleasant process, not a painful one.
I'm not saying that Hans has no faults on his side. He is arrogant too. But I do feel that he has been treated unfairly. Andrew or Linus should interfere when this happens. Christoph Hellwig clearly shouldn't be the reason that stalls the inclusion of reiser4.
Christoph Hellwig clearly sho
Christoph Hellwig clearly shouldn't be the reason that stalls the inclusion of reiser4.
Indeed. The reason for stalls is that there are still some valid issues left with Reiser 4 code which hch is pointing out.
Bias and predjudice
But what I don't understand is the process for deciding what gets accepted into the kernel. Some projects, like RFS4, are vigorously tested and have a history of consistent development, and yet are blocked from inclusion by a few people who seemingly have axes to grind. Other projects, which are buggy and immature, are accepted based on no apparent criteria other than nepotism. Maybe that's it. You have to suck dick to get code accepted into the kernel tree.
That said, Hans is an ass. Actually, many people on the LKML are asses, and it seems that the most knowledgeable and the most ignorant are the biggest ones. On the LKML, it's often easier to pick out the people who aren't asses -- the list is much shorter.
It's very clear that most peo
It's very clear that most people don't understand what the process is of getting something accepted or not.
If it has no side effects to the rest of the kernel then it has already a much bigger chance. Probably most people forgot it, but Reiser4 used to change quite a bit in the rest of the kernel, so it wasn't (and still isn't) totally stand alone.
Second big thing is if it duplicates work, or if it adds things that are also useful for others. In the first case it should use the existing means, and in the second case it should add the generally useful feature insuch way that the rest of the kernel can also use it (to prevent future duplicate work).
Another thing is if the code is following kernel coding style and if it isn't too ugly. And ugly in this sense means that it is hard to understand for other kernel developers, and that the code does do inappropriate things or is just inelegant.
Then there are always things like proper locking, being cross-platform (not the whole world is x86), and if it is using existing apis well.
Of course it's nice if it actually works and isn't too buggy, and being well tested is great too. If the thing is visible for users then it's merged more carefully. If it introduces new user APIs then those should be good. For filesystems it's important that they don't cause datacorruption and won't change the on-disk format soon.
All this is almost pure technical (with some leeway for taste differences).
If the above things are satisfied the non-technical things could prevent it from inclusion: Perhaps no one wants it? If there's no demand then it's probably not very smart to merge. It could be simply unwanted, e.g. a nice module for hooking binary drivers, or a module with a jpeg decoder built in (both exist). Or the code is good enough for merging, but the developers of that code don't push for inclusion (squashfs?).
You should realize that asking for inclusion is asking something like:
"Are you, the kernel community, willing to include my code and maintain it indefinitely?"
Seen in this light it may be more understandable that the code isn't merged before the kernel devs like it.
Reiser4 didn't pass the technical hurdle yet, and it won't if people start throwing mud to eachother everytime technical feedback is given. All Reiser4 threads are drowned in flaming, which makes it very hard to keep focussed on the technical part.
I'm reading lkml for some years now, and it isn't so bad. It's mainly bad in the big flamewar threads (the things that most people seem to read for some strange reason). In general it's very unpersonal. Code may be insulted a lot, but people who take that personally are very short sighted (welcome to the majority ;-).
Most communication is nonverbal in real life. Imagine how much is missing when communicating via the web. It's no wonder people misunderstand eachother and seem like asses.
I don't know if you Sean think that you're an ass, but read what you just wrote. You heavily insult almost all kernel developers on lkml, and Hans. That while you don't know those people, nor seem to understand what's going on lkml at all.
Bias and predjudice
"Other projects, which are buggy and immature, are accepted based on no apparent criteria other than nepotism."
What might these other projects be? Rather than just flaming your mouth off, with vague references, try some specifics, if you want people to take you seriously.
A user's input...
Linus refused ext3 initially. It went in because it had a userbase,
vendors shipping it and reliable clean code. Saying "no" a lot is really rather important to keeping the kernel maintainable. I regularly meet cases we should have said "no" a lot louder 8)
I've been using Linux for about eight years now. When SUSE started inlcuding ResierFS I used it, fell in love with it and continue to use it. It has saved my data more than once. Ext2 is too old and cumbersome to use. Ext3 is barely better than Ext2, especially when, after an unplanned reboot, it forces you to fsck even though it is 'supposed' to be a journaled filing system.
At work we started using ReiserFS when we deployed SUSE 6.4. ReiserFS is included in most major distros and is the preferred fs in many. We just installed an Oracle 10g database on a SUSE 9.3 Pro raid 10 server running ReiserFS. In my experience ReiserFS is MORE reliable than ext2 or ext3, a lot faster, and for me has never failed to recover from an uplanned reboot. That pretty well covers all of Alan Cox's 'requirements'. The 'clean code' part is in the eye of the beholder.
Keeping ReiserFS out of the kernel wouldn't be the first time that superior code has lost out to envy, jealousy, or NIH. It's already included in most major distros, so just stop the petty personality wars and add that fine fs to the kernel.
This thread is about the incl
This thread is about the inclusion of ReiserFS 4 in the stable linux kernel, not ReiserFS version 3. ReiserFS 3 has been in the kernel for a long time now. ReiserFS 4 is not in included by default in any distros that I have seen.
Thank god someone else recogn
Thank god someone else recognised this point.
DB on reiserfs
Not to mention the questionability of running a DB on top of ReiserFS.
(I'm a ReiserFS fan and use Reiser3 for a few years now and thank Hans for it, but I would check around before I put a database on it, from what I hear you better use JFS or XFS).