Re: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink

Date: Fri Feb 02 2001 - 17:58:14 EST

On Sat, Feb 03, 2001 at 01:03:00AM +0300, Hans Reiser wrote:
> My design objective in ReiserFS is not to say that it wasn't my fault they had
> that bug because they are so ignorant about a filesystem that
> really isn't very important to them unless it screws up. My design objective is
> to ensure they don't have that bug. They are more important than me.

The whole argument back and forth here seems to be:

Hans: It's better if it fails to compile with a clear message than compiling
      ok and breaking horribly and unpredictably later.
Alan: It won't work and it'll generate more mail, not less.

Now, it seems to me, as long as the ReiserFS folks are going to be getting the
bulk of the extra work(/mail/whatever) out of this, and they've been advised
of the risks to their own person and are ok with that (which they apparently
are), then they might as well go ahead and try it. It's their inboxes.

The one thing I do have to say about all of this, however, is that if this
sort of testing for compiler issues (or tool issues, or library issues or
anything else) is going to be done as part of individual kernel components,
there should be some way to globally configure this, so that it can be turned
off should someone, for some reason, want (or need) to do something with an
unsupported version of something and know what they're doing, without having
to hunt through every line of kernel source to find the multiple places
different developers have put in different checks for the thing they're
trying to do.

Perhaps a "Kernel Hacking" configuration option (or just something in a
documented .h file) for "Allow compiling with buggy GCC 2.96" which would turn
off all such checks?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed Feb 07 2001 - 21:00:16 EST