lkml.org 
[lkml]   [2006]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2009-11-18 23:46    [W:0.040 / U:30.620 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site