linux-kernel - Re: Reiser4 Inclusion

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 17 Jul 2006 15:01:35 -0400
From:	Horst von Brand <vonbrand@....utfsm.cl>
To:	Grzegorz Kulewski <kangur@...com.net>
Cc:	Diego Calleja <diegocg@...il.com>, arjan@...radead.org,
	caleb@...ebgray.com, linux-kernel@...r.kernel.org
Subject: Re: Reiser4 Inclusion 

Grzegorz Kulewski <kangur@...com.net> wrote:

[...]

> Why do some people think that users are not already depending on it? 
> They are.

Foolishly, perhaps...

>           I don't know how much but I am willing to bet that at least
> 100 people. I think that there are some drivers in the kernel that
> have smaller user base.

Feel free to suggest deleting said drivers.

> Keeping Reiser4 out of kernel is even worse (for those users, other
> users that could test this filesystem, for Reiser4 developers and
> whole comunity) than accepting it for a try period with a big fat
> warning that it my be removed if Namesys abandons futher fixing of it
> (after some time to let user migrate).

I just won't work that way. Using that logic, Reiser 3 should be gone long
ago...

> And any arguments like "if Reiser4 is not in the kernel then people
> will not use and depend on it" are fundamentally flawed
> IMHO. Everything bad that could happen with Reiser4 in the kernel can
> happen with Reiser4 out of it.

Right. But this way it is /not/ the kernel crowd's job to look after it.

> It may look like some kernel developers are trying hard not to take
> responsibility for Reiser4

Why should they? They don't feel confortable with the code, believe it has
fatal design (and other) problems. Its maintainers have shown a tendency to
disregard data safety, and just dump the code when something new fancies
them. The kernel hackers can't just take over any random piece of complex
code, the only scalable way of integrating new stuff that will stay for a
/long/ time is to have reasonable expectations that whoever proposes the
code will stay around maintaining it.

>                            saying that there is very huge difference
> between selecting highly experimental kernel feature that is marked so
> and patching the kernel with it. Sorry but I think there is very
> little difference. And that little difference is only hurting users
> that want to try and test something new.

If it is in the kernel, the expectation is that it will stay in the kernel
for the foreseeable future. For a filesystem, something like the next 10
years. Thus letting in a new filesystem is a /huge/ commitment.
-- 
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/