linux-kernel - Re: metadata plugins (was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding 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:	Fri, 28 Jul 2006 09:33:56 -0700 (PDT)
From:	Linus Torvalds <torvalds@...l.org>
To:	David Masover <ninja@...phack.com>
cc:	"Horst H. von Brand" <vonbrand@....utfsm.cl>,
	Jeff Garzik <jeff@...zik.org>,
	Hans Reiser <reiser@...esys.com>,
	Andrew Morton <akpm@...l.org>, Theodore Tso <tytso@....edu>,
	LKML <linux-kernel@...r.kernel.org>,
	ReiserFS List <reiserfs-list@...esys.com>
Subject: Re: metadata plugins (was Re: the " 'official' point of view"
 expressed by kernelnewbies.org regarding reiser4 inclusion)

On Fri, 28 Jul 2006, David Masover wrote:
> 
> But what's wrong with people doing such experiments outside the kernel?
> AFAICS, "exotic, site-specific one" is not something that would be considered
> for inclusion.

Here's a few ground rules at least from my viewpoint:

 - as long you call them "plugins" and treat them as such, I (and I 
   suspect a lot of other people) are totally uninterested, and in fact, a 
   lot of people will suspect that the primary aim is to either subvert 
   the kernel copyright rules, or at best to create a mess of incompatible 
   semantics with no sane overlying rules for locking etc.

 - the kernel does not, and _will_ not, support "hooks" that aren't 
   actually used (and make sense) by normal kernel uses, for largely the 
   same reasons. Interfaces need to be architected, make sense, and have 
   real and valid GPL'd uses.

In other words, if a filesystem wants to do something fancy, it needs to 
do so WITH THE VFS LAYER, not as some plugin architecture of its own. We 
already have exactly the plugin interface we need, and it literally _is_ 
the VFS interfaces - you can plug in your own filesystems with 
"register_filesystem()", which in turn indirectly allows you to plug in 
your per-file and per-directory operations for things like lookup etc.

If that isn't enough, then the filesystem shouldn't make its own internal 
plug-in architecture that bypasses the VFS layer and exposes functionality 
that isn't necessarily sane. For example, reiser4 used to have (perhaps 
still does) these cool files that can be both directories and links, and I 
don't mind that at all, but I _do_ mind the fact that when Al Viro (long 
long ago) pointed out serious locking issues with them, those seemed to be 
totally brushed away.

So as far as I'm concerned, the problem with reiser4 is that it hasn't 
tried to work with the VFS people. Now, I realize that the main VFS people 
aren't always easy to work with (Al and Christoph, take a bow), but that 
doesn't really change the basic facts. Al in particular is _always_ right. 
I don't think I've ever had the cojones to argue with Al..

			Linus
-
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/