[lkml]   [2005]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: reiser4 plugins
    Hash: SHA1

    Lincoln Dale wrote:


    > this is the WHOLE point of standardization .. i don't think its that
    > Reiser4's EAs offer any more or less capabilities than standard EAs -

    They do. Reiser4's EAs can look like any other object -- files,
    folders, symlinks, whatever. This is important, especially for

    For one thing, can I access a Beagle search as a folder?

    > BUT they haven't used the standard mechanisms available for implementing
    > them, such for Beagle to work on Reiser4, there now needs to be logic
    > added to Beagle to do so.

    Well, ideally, I'd like to see people stop bickering, come up with
    something better than sys_reiser4, add an emulation layer for xattrs and
    mark them obsolete.

    But I don't speak for Namesys.

    > lets take this a step further. what about compression? do we accept
    > that each filesystem can implement its own proprietary compression via
    > its own API - and now we need individual user-space tools to understand

    No, that's the beauty of these "EAs" in Reiser4. The API is standard
    write(2) commands. sys_reiser4 supposedly implements an interface to
    make this scale better, but otherwise have the same semantics. And who
    said anything about proprietary compression? I think we were planning
    on the kernel's zlib, though we might have been planning to make it a
    bit more seekable...

    > each of these APIs?

    So, the API becomes something like:

    cat crypto/inflated/foo # transparently decompressed
    cat crypto/raw/foo.gz # raw, gzip-compressed

    Another possibility, if you like file-as-a-directory:

    cat foo.gz # raw
    cat foo.gz/inflated # decompressed

    One could easily imagine things like these two potentially equivalent

    cp foo
    zip bar foo

    The whole point is to have less userland tools, not more. I'm not
    saying we move zip into the kernel, just that the user now has one less
    command to remember.

    But, back to reality. file-as-directory probably won't happen, at least
    not for awhile, so imagine more along the lines of my first example.

    > how about encryption?

    About the same, only now you have a key file that you write to in order
    to unlock the decrypted files.

    > ... and so-on.
    > suddenly every user app out there needs to have specialized knowledge of
    > each type of filesystem.

    Not really.

    More like, every app that cares to has generalized knowledge, if that.

    > none of this is rocket-science. its just plain common sense.

    I could say the same of my stuff, but lots of people seem to disagree
    with me, or at least fail to see it. I guess I can say the same of your

    >> It's a filesysem for gods sake. Hans and his team have worked hard to
    >> minimize its impact and they are still willing to accept more
    >> guidance,
    > i don't see any acceptance at this point. simply lots of hot air that
    > smells like marketing & PR.

    They do keep asking for specifically what they need to do to put this
    stuff in VFS. Or am I wrong?

    Or maybe it should be obvious to them?

    Version: GnuPG v1.4.1 (GNU/Linux)
    Comment: Using GnuPG with Thunderbird -

    -----END PGP SIGNATURE-----
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-06-26 09:53    [W:0.027 / U:18.244 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site