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

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.234 / U:4.196 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site