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 17:56:10 +0200
From:	Matthias Andree <matthias.andree@....de>
To:	Jeff Anderson-Lee <jonah@...s.berkeley.edu>
Cc:	'fsdevel' <linux-fsdevel@...r.kernel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: Reiser4 Inclusion

On Mon, 17 Jul 2006, Jeff Anderson-Lee wrote:

> I saw a log-structured file system being developed as a Google summer
> project recently.  It's likely doomed to obscurity by the fs-related
> code-churning in the Linux kernel.  Since it is "experimental" it won't be
> included in the kernel distribution and hence won't get the benefit of
> kernel developers making sweeping changes that touch all the file system
> dependent code.  You practically need it to be your full-time job in order
> to do any research or development work under Linux with this kind of
> environment.

> 2) A lessening (moratorium?) on sweeping changes for a while, so that FS
> developers would have a chance to try new ideas without being flooded with
> changes needed just to keep up with the latest kernel, or

Other suggestions:

- try it on 2.6.16.X which is supposed to be longer-lived, and forward
  port as that system is discontinued.

- see if you can implement your concepts in user space (FUSE). If there
  are sufficient advantages, port it to the kernel.

> Of these: (1) is likely impractical, as it imposes an additional burden on
> kernel developers to support obscure or experimental f/s.  (2) is only a
> stop-gap, as at some point sweeping changes might again be made that would
> out-date most experimental f/s.  (3) seems the most logical course: work
> towards a better interface between the FS dependent and independent layers
> (e.g. VFS, mm) that does a better job of isolating the layers from each
> other.

Linux developers have often uttered their unwillingness for stable
interfaces.

> Without that, *BSD (and now possibly OpenSolaris) will be preferred over
> Linux for FS research, which typically means that few if any people benefit
> from the results: a loss for both Linux and the community at large.

If the file system is so crucial for the intended application, would not
its choice alone dominate over all other criteria and demote the weight
of the OS rather "convenience" or "it's just a name"?

-- 
Matthias Andree
-
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/