lkml.org 
[lkml]   [2004]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: silent semantic changes with reiser4
    Andrew Morton wrote:

    >Hans Reiser <reiser@namesys.com> wrote:
    >
    >
    >>I had not intended to respond to this because I have nothing positive to
    >>say, but Andrew said I needed to respond and suggested I should copy
    >>Linus.
    >>
    >>
    >
    >Yes, but I didn't say "flame Christoph and ignore the issues" ;)
    >
    >
    Oh....;-)

    >There are lots of little things to do with implementation, coding style,
    >module exports, deadlocks, what code goes where, etc. These are all normal
    >daily kernel business and we should set them aside for now and concentrate
    >on the bigger issues.
    >
    >
    Yes, you are right, but I am not sure Viro will go along with that..... ;-)

    >And as I see it, there are two big issues:
    >
    >a) reiser4 extends the Linux API in ways which POSIX/Unix/etc do not
    > anticipate and
    >
    >b) it does this within the context of just a single filesystem.
    >
    >I see three possible responses:
    >
    >a) accept the reiser4-only extensions as-is (possibly with post-review
    > modifications, of course) or
    >
    >b) accept the reiser4-only extensions with a view to turning them into
    > kernel-wide extensions at some time in the future, so all filesystems
    > will offer the extensions (as much as poss) or
    >
    >c) reject the extensions.
    >
    >
    >My own order of preference is b) c) a).
    >
    I don't object to b), though I think b) should wait for 2.7 and reiser4
    should not.

    > The fact that one filesystem will
    >offer features which other filesystems do not and cannot offer makes me
    >queasy for some reason.
    >
    >
    Andrew, we need to compete with WinFS and Dominic Giampaolo's filesystem
    for Apple, and that means we need to put search engine and database
    functionality into the filesystem. It takes 11 years of serious
    research to build a clean storage layer able to handle doing that.
    Reiser4 has done that, finally. None of the other Linux filesystems
    have. The next major release of ReiserFS is going to be bursting with
    semantic enhancements, because the prerequisites for them are in place
    now. None of the other Linux filesystems have those prerequisites.
    They won't be able to keep up with the semantic enhancements. This
    metafiles and file-directories stuff is actually fairly trivial stuff.

    Look guys, in 1993 I anticipated the battle would be here, and I build
    the foundation for a defensive tower right at the spot MS and Apple are
    now maneuvering towards. Help me get the next level on the tower before
    they get here. It is one hell of a foundation, they won't be able to
    shake it, their trees are not as powerful. Don't move reiser4 into vfs,
    use reiser4 as the vfs. Don't write filesystems, write file plugins and
    disk format plugins and all the other kinds of plugins, and you won't be
    missing any expressive power that you really want....

    Give Saveliev and I some credit. 10 years of hard work at an ivory
    tower nobody thought mattered. Now the battle leaves the browser and
    swings our way. Don't duplicate that infrastructure, use it.

    There is so much we could use help with if talented people like you
    chose to contribute.

    >b) means that at some time in the future we need to hoist the reiser4
    >extensions (at a conceptual level) (and probably with restrictions) up into
    >the VFS. This will involve much thought, argument and work.
    >
    >
    >To get us started on this route it would really help me (and, probably,
    >others) if you could describe what these API extensions are in a very
    >simple way, without referring to incomprehehsible web pages,
    >
    what is not comprehensible....?

    > and without
    >using terms which non-reiser4 people don't understand.
    >
    >
    Well, I agree that there is value in defining things in more detail than
    we have.

    >It would be best if each extension was addressed in a separate email
    >thread.
    >
    >We also need to discuss what a reiser4 "module" is, what its capabilities
    >are, and what licensing implications they have.
    >
    >Then, we can look at each one and say "yup, that makes sense - we want
    >Linux to do that" and we can also think about how we would implement it at
    >the VFS level.
    >
    >If we follow the above route I believe we can make progress in a technical
    >direction and not get deadlocked on personal/political stuff.
    >
    >
    >Now, an alternative to all the above is to just merge reiser4 as-is, after
    >addressing all the lower-level coding issues. And see what happens. That
    >may be a thing which Linus wishes to do. I'm easy.
    >
    >
    >
    >

    -
    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: 2005-03-22 14:05    [W:4.298 / U:0.292 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site