linux-kernel - Re: reiser4: maybe just fix bugs?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <200607311617.k6VGH3YH009055@laptop13.inf.utfsm.cl>
Date:	Mon, 31 Jul 2006 12:17:03 -0400
From:	"Horst H. von Brand" <vonbrand@....utfsm.cl>
To:	"Denis Vlasenko" <vda.linux@...glemail.com>
cc:	reiser@...esys.com, linux-kernel@...r.kernel.org
Subject: Re: reiser4: maybe just fix bugs? 

Denis Vlasenko <vda.linux@...glemail.com> wrote:
> The reiser4 thread seem to be longer than usual.
> Let me, a mere user, add some input.

Please don't.

> It looks to me that delay with reiser4 acceptance
> is caused by two different things.
> 
> First, reiser4 adds those plugins which many FS people
> see as belonging to VFS layer rather than to particular FS.

Right.

> And second, reiser team was a bit lax at fixing bugs.

Right!

> Not too bad when compared to other FSes, but still.

How did you compare?

> When singled out, none of these things are bad enough to hold off
> inclusion. However, combined impact of _both_ of them
> did upset maintainers enough.

Plus a, lets say, less than cooperative overall attitude, and a marked
tendency to try to sneak changes in by political arm-twisting.

> Frankly, on the first problem I think that you are right, Hans, and
> putting plugins into VFS _now_ makes little sense because we can't know
> whether anybody will ever want to have plugins for some other FS, so
> requiring reiser people to do all the shuffling _now_ for questionable
> gain is simply not fair. It can be done later if needed.

You are wrong. ReiserFS has no "right" to be allowed into the kernel. If
the people in charge of maintaining the filesystem infrastructure of the
kernel say something about your patches, you either take heed (and so
increase your chance of being accepted someday), or stay out. It is /their/
game, after all.

> It leaves you with the other option: remove the second problem.

That has to be done regardless. Buggy code with authors that can't be
bothered to fix it just means more work for the (thinly spread) kernel
hackers, so it is an absolute no-no-no.
-- 
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/