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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [RFC][PATCH] VFS: update documentation (take #2)
    ... > filesystem interface to userspace programs. ... > abstraction within the kernel which allows different filesystem ... > a pointer to the dentry and a set of file operation member functions. ... called when the VFS needs to get filesystem statistics. ...
    (Linux-Kernel)
  • [PATCH] VFS: update documentation
    ... The Virtual File System (otherwise known as the Virtual Filesystem ... Switch) is the software layer in the kernel that provides the ... The VFS implements the open, stat, chmodand similar system ... struct file_system_type { ...
    (Linux-Kernel)
  • Re: [PATCH] VFS: update documentation
    ... The Virtual File System (otherwise known as the Virtual Filesystem ... Switch) is the software layer in the kernel that provides the ... The VFS implements the open, stat, chmodand similar system ... struct file_system_type { ...
    (Linux-Kernel)
  • Re: sfill tool fails with filesize limit exceeded
    ... >> does this mean I have to recompile the kernel for large file ... >> support? ... > Which filesystem on which architecture are you using? ...
    (comp.security.unix)
  • Re: How to monitor Linux file system operations
    ... You should only write a module if you want to write you own filesystem ... Then you should implement the VFS ... so I think it's not only my own file system. ... Instead, as of kernel 2.6.13-rc3 ...
    (comp.os.linux.development.system)