🚀 go-pugleaf

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

[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

On Fri, Sep 16, 2005 at 12:39:48PM -0700, Hans Reiser wrote:
> 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.
>
> (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......)

Well my experience with XFS for about 6 months using 2.6 kernels has
been about as good as my experience with reiserfs 3.6 back when 2.4
was fairly new.

That's why I run ext3.

I don't need my filesystem locking up, leaking memory all over the
place, causing processes to be killed byt the out of memory handler,
etc.  I will stick with what works all the time.

Performance and nifty features are fun, but only when they don't break
your system.

Len Sorensen

On Fri, Sep 16, 2005 at 04:50:45PM -0400, Lennart Sorensen wrote:
> Well my experience with XFS for about 6 months using 2.6 kernels has
> been about as good as my experience with reiserfs 3.6 back when 2.4
> was fairly new.
>
> That's why I run ext3.
>
> I don't need my filesystem locking up, leaking memory all over the
> place, causing processes to be killed byt the out of memory handler,
> etc.  I will stick with what works all the time.
>
> Performance and nifty features are fun, but only when they don't break
> your system.

In other words that means: Neither was ready for use when they were
included in the kernel and should probably have had big warning signs in
the kernel config for them.  They also seem sufficiently complex that
fixing them is very hard work.

Len Sorensen

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.

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.

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

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

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

> 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

On Friday 16 September 2005 20:05, Hans Reiser wrote:
> All objections have now been addressed so far as I can discern.

Random observation:

You can declare functions even if you never use them.
Thus here you can avoid using #if/#endif:

#if defined(REISER4_DEBUG) || defined(REISER4_DEBUG_MODIFY) || defined(REISER4_DEBUG_OUTPUT)
int znode_is_loaded(const znode * node /* znode to query */ );
#endif

--
vda

On Sat, Sep 17, 2005 at 02:16:20PM +0300, Denis Vlasenko wrote:
> Random observation:
>
> You can declare functions even if you never use them.
> Thus here you can avoid using #if/#endif:
>
> #if defined(REISER4_DEBUG) || defined(REISER4_DEBUG_MODIFY) || defined(REISER4_DEBUG_OUTPUT)
> int znode_is_loaded(const znode * node /* znode to query */ );
> #endif

   What is wrong with documentation, in your opinion?

--nextPart8365185.0ZjyuWgaIn
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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

--nextPart8365185.0ZjyuWgaIn
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQBDLLYqFdQwWVoAgN4RAqLiAJ45bbLt80lAjBr7n60OzhWS6Lw4XwCcCM9S
wAcGa8G84ZhHCCkL4iJHRFw=RlIP
-----END PGP SIGNATURE-----

--nextPart8365185.0ZjyuWgaIn--

On Sat, Sep 17, 2005 at 01:56:14PM +0300, 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 romfs is smaller than ext2, damn.  Should we remove all filesystems but
romfs now?


and yeah, if you didn't get the hint compare the feature sets.

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)

I threw in your new codedrop into a compilation and the byte-order
mess is _still_ now sorted out.  Please kill the d* as struct type
crap and just use __le types directly.

Also lots of "memset with byte count of 0" warnings from sparse.

Christoph Hellwig wrote:
> On Sat, Sep 17, 2005 at 01:56:14PM +0300, 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 romfs is smaller than ext2, damn.  Should we remove all filesystems but
> romfs now?
>
>
> and yeah, if you didn't get the hint compare the feature sets.

XFS does have a nice feature set, sure.  So does Reiser4.

XFS can "freeze" the filesystem, take a live snapshot, and do some
other, similar tricks.  Reiser4 can show file metadata as files
themselves, compress on-the-fly (last I checked, the compression code is
in there, just not being used), and pack small files incredibly well.

XFS has xattrs.  Reiser has metas, and will eventually provide an xattr
interface to them.

You may not value Reiser's feature set, but that doesn't make it less
complex.  Romfs is actually simpler than ext2, and its whole "feature"
seems to be having a tiny implementation.

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

On 9/18/05, Christoph Hellwig <hch@infradead.org> 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.

Denis Vlasenko wrote:

> If you want reiser4 included into mainline, do something. Like download
> a patch and try to use it.

Alright...

> Last time I tried, it didn't work. Kernel locked up. Namesys was quick
> with fix for the lockup, but then "ls ." failed to work. I sent all
> the data (kernel version, fs image, etc) to Namesys but after several
> email iterations it died out with no resolution.

When was "last time"?

> I will try again sometime. Maybe it got better.

I have three boxes running Reiser4 for everything except /boot, and no
problems yet, except an occasional missing feature, like a
repacker/resizer.  One's a Pentium 3, the other two are amd64s.

I've had a total of one crash each on the amd64s, and one of those was
while playing a game, and could easily have been the nvidia drivers.  I
can't reproduce the other one, and the box has been fine since -- and
both amd64s are overclocked by 600 mhz, so I have a sneaking suspicion
that it might have been hardware.

No crashes yet on the Pentium 3, which isn't overclocked at all.

No lost data yet either, in fact, I recovered from an essential 'rm -rf'
of a Reiser4 partition, so I could even say Reiser4 (or rather,
fsck.reiser4) has *found* data for me.



For a long time, it's been painfully obvious that the reasons Reiser4
isn't in the kernel all have to do with things like coding style and
politics.  At this point, if I tried to do anything more than be an
active user, I'd be so far out of my depth I'd need a life jacket.

Denis Vlasenko writes:
 > On Friday 16 September 2005 20:05, Hans Reiser wrote:
 > > All objections have now been addressed so far as I can discern.
 >
 > Random observation:
 >
 > You can declare functions even if you never use them.
 > Thus here you can avoid using #if/#endif:
 >
 > #if defined(REISER4_DEBUG) || defined(REISER4_DEBUG_MODIFY) || defined(REISER4_DEBUG_OUTPUT)
 > int znode_is_loaded(const znode * node /* znode to query */ );
 > #endif

It's other way around: declaration is guarded by the preprocessor
conditional so that nobody accidentally use znode_is_loaded() outside of
the debugging mode.

 >
 > --
 > vda
 >

Nikita.

On Sunday 18 September 2005 12:26, Christoph Hellwig 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 that and there's much more exciting filesystems like ocfs2
> around [...]

Now _what_ good does that sentence do us? I've been following this this since
the primary reiser filesystem was number 3, and the kernel everybody was
using was 2.4.10. You've probably been following this list for far longer,
but is that really an excuse for rudeness?

reiser4 has many, many extremely interesting features. I'm sure anybody is
more than willing to go into detail with them, but saying that "ocfs2 is much
more exiting" is just plain bashing, and it's not fair to Hans, to Namesys,
or to every one of us who can't wait for reiser4 in mainline.

Could you please keep your personal idea of which filesystem is more
interesting to yourself? It doesn't help anybody accomplish anything.

--
Regards,
Christian Iversen
(not affiliated with namesys..)

Denis Vlasenko wrote:

>On Friday 16 September 2005 20:05, Hans Reiser wrote:
>
>
>>All objections have now been addressed so far as I can discern.
>>
>>
>
>Random observation:
>
>You can declare functions even if you never use them.
>Thus here you can avoid using #if/#endif:
>
>#if defined(REISER4_DEBUG) || defined(REISER4_DEBUG_MODIFY) || defined(REISER4_DEBUG_OUTPUT)
>int znode_is_loaded(const znode * node /* znode to query */ );
>#endif
>
>--
>vda
>
>
>
>
thanks.

zam, please address this.

--==_Exmh_1127071009_9673P
Content-Type: text/plain; charset=us-ascii

On Sun, 18 Sep 2005 13:22:27 EDT, michael chang said:

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

There's nothing wrong with discriminating against the guy in the wheelchair
under some circumstances - for instance, when your track team needs a new
high jumper.

Similarly, when the goal is to build a set of developers that can actually
get work accomplished, poor interpersonal communication skills can be a
major problem.

If the problem is that Hans and the rest of the kernel developers don't get
along, perhaps the most expedient thing would be for Hans to step out of the
way and have somebody else from Namesys (or elsewhere even) act as the interface.

--==_Exmh_1127071009_9673P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFDLb0hcC3lWbTT17ARAh78AKCUBibrT7caXvhfNVC1teNqbcugnwCgkgWX
uJb21oCrWCsYfP9lo6/zlWA=onP7
-----END PGP SIGNATURE-----

--==_Exmh_1127071009_9673P--

On Sunday 18 September 2005 15:06, Christian Iversen wrote:
> On Sunday 18 September 2005 12:26, Christoph Hellwig 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 that and there's much more exciting filesystems like ocfs2
> > around [...]
>
> Now _what_ good does that sentence do us? I've been following this this since
> the primary reiser filesystem was number 3, and the kernel everybody was
> using was 2.4.10. You've probably been following this list for far longer,
> but is that really an excuse for rudeness?
>
> reiser4 has many, many extremely interesting features. I'm sure anybody is
> more than willing to go into detail with them, but saying that "ocfs2 is much
> more exiting" is just plain bashing, and it's not fair to Hans, to Namesys,
> or to every one of us who can't wait for reiser4 in mainline.

"every one of us who can't wait" do not count, because they do nothing.

If you want reiser4 included into mainline, do something. Like download
a patch and try to use it.

Last time I tried, it didn't work. Kernel locked up. Namesys was quick
with fix for the lockup, but then "ls ." failed to work. I sent all
the data (kernel version, fs image, etc) to Namesys but after several
email iterations it died out with no resolution.

I will try again sometime. Maybe it got better.

> Could you please keep your personal idea of which filesystem is more
> interesting to yourself? It doesn't help anybody accomplish anything.

Your reply wasn't polite/useful either.
--
vda

On Sep 18, 2005, at 13:22:27, michael chang wrote:
> On 9/18/05, Christoph Hellwig <hch@infradead.org> 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".
>>
>> that and there's much more exciting filesystems like ocfs2 around
>> that
>
> This is exciting to... whom?

To the people that review the code.  We're all volunteers here; if
your filesystem is so ugly and hard to read that the code reviewers
don't feel like finding time to slog through the mess, then it
probably means that you need to clean the code, document it better,
make it simpler to understand, fix the coding-style, etc.

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

Like I said above, we're all volunteers.  Personally, I find OCFS2
_much_ more interesting than reiser4, because it has a lot of cool
networked lock-managing algorithms that (given my current limited
understanding), work black magic.  Given this, I'm a lot more likely
to spend time reading the OCFS2 code because its interesting than I
am reading reiser4 code, even though somebody eventually probably
needs to do said review.  Hans' personal attacks on the people who
have criticized his code make such tasks even less personally
gratifying (IE: less interesting).  I think some people are likely
hoping right now that if they put off the reiser4 code review long
enough, maybe the authors will take a hint and have it a bit cleaner
by the time they finally do get around to the review.

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

When you start getting into obscure discrimination analogies, the
discussion has become _way_ nontechnical.  If this goes this goes any
further, somebody's probably going to compare a kernel developer to a
Nazi or Hitler, invoking Godwin's law and effectively killing the
thread.  Please get this back onto a technical bent or drop it.

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

Christoph has noted a number of things in previous emails.  I just
looked through the latest released code and several of them are still
valid.  I would look through the latest code to see what is still
missing, but I can't get it on account of it being in bitkeeper,
which I don't have installed and don't intend to install.

> I'm willing to go compare...  [massive nontechnical rhetoric snipped]

Unless you have technical arguments to contribute (and you indicate
that you do not), please to not spam the LKML with useless rhetoric-
filled emails that most of us will delete because we have too many
other things to do to bother reading or responding to.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$ L++++(+
++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+
++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  !y?(-)
------END GEEK CODE BLOCK------

On 9/18/05, Kyle Moffett <mrmacman_g4@mac.com> wrote:
> On Sep 18, 2005, at 13:22:27, michael chang wrote:
> > On 9/18/05, Christoph Hellwig <hch@infradead.org> 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".
> >>
> >> that and there's much more exciting filesystems like ocfs2 around
> >> that
> >
> > This is exciting to... whom?
>
> To the people that review the code.  We're all volunteers here; if
> your filesystem is so ugly and hard to read that the code reviewers
> don't feel like finding time to slog through the mess, then it
> probably means that you need to clean the code, document it better,
> make it simpler to understand, fix the coding-style, etc.
>
> > 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.)
>
> Like I said above, we're all volunteers.  Personally, I find OCFS2
> _much_ more interesting than reiser4, because it has a lot of cool
> networked lock-managing algorithms that (given my current limited
> understanding), work black magic.  Given this, I'm a lot more likely
> to spend time reading the OCFS2 code because its interesting than I
> am reading reiser4 code, even though somebody eventually probably
> needs to do said review.  Hans' personal attacks on the people who
> have criticized his code make such tasks even less personally
> gratifying (IE: less interesting).  I think some people are likely
> hoping right now that if they put off the reiser4 code review long
> enough, maybe the authors will take a hint and have it a bit cleaner
> by the time they finally do get around to the review.
>
> > 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.
>
> When you start getting into obscure discrimination analogies, the
> discussion has become _way_ nontechnical.  If this goes this goes any
> further, somebody's probably going to compare a kernel developer to a
> Nazi or Hitler, invoking Godwin's law and effectively killing the
> thread.  Please get this back onto a technical bent or drop it.
>
> > 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.
>
> Christoph has noted a number of things in previous emails.  I just
> looked through the latest released code and several of them are still
> valid.  I would look through the latest code to see what is still
> missing, but I can't get it on account of it being in bitkeeper,
> which I don't have installed and don't intend to install.
>
> > I'm willing to go compare...  [massive nontechnical rhetoric snipped]
>
> Unless you have technical arguments to contribute (and you indicate
> that you do not), please to not spam the LKML with useless rhetoric-
> filled emails that most of us will delete because we have too many
> other things to do to bother reading or responding to.
>

Alright, I concede.

Personally, I'm not much of a techie compared to you guys; I'm only in
High School, and I have a mental disorder
(http://en.wikipedia.org/wiki/Asperger's_Syndrome), so I'll stop here,
and hope that you guys can resolve this yourselves.  Good luck to all,
and hopefully there will be a peaceful resolution here.

--
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.

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.

Lennart Sorensen wrote:

>
> Neither was ready for use when they were
>included in the kernel and should probably have had big warning signs in
>the kernel config for them.
>
>
They did have warning signs: they were labeled experimental....  as is
reiser4.

At some point developers and their limited size mailing list simply
cannot make things crash, and then it needs to go in to the main kernel
labeled experimental.

Of course, the reiser4 code is not as stable as it was before the
changes Christoph asked for.

Hans

Christian Iversen wrote:

>On Sunday 18 September 2005 12:26, Christoph Hellwig 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 that and there's much more exciting filesystems like ocfs2
>>around [...]
>>
>>
>
>Now _what_ good does that sentence do us? I've been following this this since
>the primary reiser filesystem was number 3, and the kernel everybody was
>using was 2.4.10. You've probably been following this list for far longer,
>but is that really an excuse for rudeness?
>
>reiser4 has many, many extremely interesting features. I'm sure anybody is
>more than willing to go into detail with them, but saying that "ocfs2 is much
>more exiting" is just plain bashing, and it's not fair to Hans, to Namesys,
>or to every one of us who can't wait for reiser4 in mainline.
>
>Could you please keep your personal idea of which filesystem is more
>interesting to yourself? It doesn't help anybody accomplish anything.
>
>
>
Hellwig, people who write slow file systems should not lecture their
measurably superiors on how to code.  Oh, and I should mention that
other people besides me have measured reiser4, and concluded it is twice
the speed of the other Linux filesystems, so don't go claiming it is
just my benchmarks.   What you are doing is keeping me from doing a real
code review myself by keeping my guys so busy that they don't have time
to review the fixmes I inserted and would insert more of if I thought
they had time for them.   If you were as well suited to doing code
reviews as I am, you would have written a faster file system yourself.
Anybody can find things to fix in someone else's code, and it can go on
for years if they want it to.  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.  We are doing work, and you
are getting in the way.  Nobody who wants reiser4 views your
contributions as the least bit positive.  I fear you will delay us until
ext3 can catch up.

What you are is someone who substitutes social connections for technical
ability.  You measurably can't code as well as we can, so once it
conforms to VFS interface requirements, please go away.

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

Valdis.Kletnieks@vt.edu wrote:

>
>
> Hans, unfortunately the most obvious reading of the above is
> "Reiser4 is so damned fast because it doesn't bother doing
> sanity-checking".

Hmm, you seem to have forgotten the Hellwig complaints about too many
assertions..... ;-)

Algorithms make a difference Valdis, they make a big difference.
> If there's still more "fixmes" to be inserted that *you* know of,
> and there are so many that there's no time to fix them, why is this
> being submitted for inclusion?

The fixmes are not bugs, those got fixed, they are "this code would be
cleaner if written another way", or, most commonly, "where is the
comment that ought to be here?"

> On Sun, 18 Sep 2005 22:09:08 PDT, Hans Reiser said:
>
>> Of course, the reiser4 code is not as stable as it was before the
>> changes Christoph asked for.
>
>
> This sort of claim requires proof - can you point at *specific*
> things that were less stable after you fixed the code, including
> explaining why they're less stable?

The 4k stacks got a bug report or two.   Generally speaking, I don't
trust any large number of lines of code of changes to be bug free, and
the VFS stuff was a large number of lines.

--==_Exmh_1127109414_2682P
Content-Type: text/plain; charset=us-ascii

On Sun, 18 Sep 2005 22:16:11 PDT, Hans Reiser said:

> Hellwig, people who write slow file systems should not lecture their
> measurably superiors on how to code.  Oh, and I should mention that
> other people besides me have measured reiser4, and concluded it is twice
> the speed of the other Linux filesystems, so don't go claiming it is
> just my benchmarks.   What you are doing is keeping me from doing a real
> code review myself by keeping my guys so busy that they don't have time
> to review the fixmes I inserted and would insert more of if I thought
> they had time for them.

Hans, unfortunately the most obvious reading of the above is "Reiser4 is so
damned fast because it doesn't bother doing sanity-checking".  If there's still
more "fixmes" to be inserted that *you* know of, and there are so many that
there's no time to fix them, why is this being submitted for inclusion?

On Sun, 18 Sep 2005 22:09:08 PDT, Hans Reiser said:
> Of course, the reiser4 code is not as stable as it was before the
> changes Christoph asked for.

This sort of claim requires proof - can you point at *specific* things that
were less stable after you fixed the code, including explaining why they're
less stable?

--==_Exmh_1127109414_2682P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFDLlMmcC3lWbTT17ARAoI+AKCmzQSVJpcH0t+/LF7ihegfixcmJACePBRc
4x5F5HgNI/8rOcCnYmn9E7g=wtgW
-----END PGP SIGNATURE-----

--==_Exmh_1127109414_2682P--

On Mon, Sep 19, 2005 at 01:18:58PM +0400, Vladimir V. Saveliev wrote:
> Hello
>
> Christoph Hellwig wrote:
> > I threw in your new codedrop into a compilation and the byte-order
> > mess is _still_ now sorted out.
>
> Did compiling notice this mess?
> We used to compile with C=1. Should we compile somehow else before sending code out?

Log is at:

	http://verein.lst.de/~hch/reiser4.log

C=1 with whatever sparse version I had, nevermind what version it is code
is not good, just use __le types instead of structs and casting exercises,
makes the code simpler and easier to verify.

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

Hello

Christoph Hellwig wrote:
> I threw in your new codedrop into a compilation and the byte-order
> mess is _still_ now sorted out.

Did compiling notice this mess?
We used to compile with C=1. Should we compile somehow else before sending code out?

> Please kill the d* as struct type
> crap and just use __le types directly.
>
ok

> Also lots of "memset with byte count of 0" warnings from sparse.
>

Running make C=1 fs/reiser4/ with sparse from http://www.codemonkey.org.uk/projects/git-snapshots/sparse/sparse-2005-09-19.tar.gz
does not produce any warnings.
Would you please prompt how to make sparse to complain?

On Mon, Sep 19, 2005 at 01:18:58PM +0400, Vladimir V. Saveliev wrote:
> Christoph Hellwig wrote:
> > I threw in your new codedrop into a compilation and the byte-order
> > mess is _still_ now sorted out.
>
> Did compiling notice this mess?
> We used to compile with C=1. Should we compile somehow else before sending code out?

Yes.

	make C=1 CF=-Wbitwise fs/reiser4/
or
	make C=1 CHECK="sparse -Wbitwise" fs/reiser4/

All coming from dformat.h