lkml.org 
[lkml]   [2005]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: reiser4 plugins
    From
    Date
    On Sun, 26 Jun 2005 02:48:06 CDT, David Masover said:

    > 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
    > transparency.

    No, you want them to look like the same objects that {get|set}xattr() manage
    currently. You don't want programs to have to guess what an EA looks like
    this week, with this user's combination of plugins that's different from
    everybody else's.

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

    And 'cat crypto/raw/foo' or 'crypto/inflated/foo.gz' gets you what, exactly?

    Now throw some .bz2 and .zip files into the mix... ;)

    > 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
    > commands:
    >
    > cp foo bar.zip/
    > zip bar foo

    Unless of course the user had done 'mkdir sorted.by.city.zip' to make
    a directory of files containing data sorted by USPS Zip code.

    And what happens if the user has a file 'bar' that's not a ZIP file,
    and a directory 'bar.zip' isn't a view into 'bar'?

    Most of the time, if I have a file 'linux-2.6.12.tar.bz2' and a
    directory 'linux-2.6.12', what is under the directory is *NOT* the same
    data as what's in the .bz2 - I've done 'make oldconfig' and a few builds
    and some variable amount of patching, usually with rejects, and I *don't*
    want that .bz2 being updated during all this (hint - what's my next command
    after 'rm -rf linux-2.6.12' likely to be, and why, and what expectations
    do I have when I do it?)

    You want to think this sort of thing through *really* thoroughly, because
    there's a *lot* of things, both users and programs, that have expectations
    about The Way Things Work.

    > 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 now instead of having to remember the one meme "I can manage any
    compressed-archive format that's stored in a file, and put other files in it,
    and all I need is the appropriate userspace tool", they have to remember "the
    cp trick works for .zip and .tar, but I'll get a "not a directory" error if I
    try it with a .hqx file, and that other file format may or may not work,
    because I can't remember if this kernel has a working out-of-tree module for
    this kernel...."

    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2005-06-26 20:24    [W:4.106 / U:0.912 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site