Re: reiser4 plugins

[David Masover]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Valdis.Kletnieks@xxxxxx wrote:
> 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.

"Plugins" is a bad word.  This user's combination of plugins is most
likely identical to other users', it's just which ones are enabled, and
which aren't?  If they are all included, I assume they play nice.

And just because they are called "plugins" doesn't mean the EA looks
different every week.

I cannot stress this enough.  In Reiser4, EVERYTHING is some sort of
plugin.  We now have a standard disk format plugin, and a standard set
of plugins providing UNIX filesystem-like things (vanilla files,
directories, symlinks, device nodes, named pipes...) which has been
stable for some time.

I see no problems with providing at least as consistent an EA interface
as any other FS, only more extensible because it's not flat.

>>>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... ;)

Interface is the same.  Only, zip files aren't just compression, so
maybe the interface changes a little there.

Point is, now you have a standard interface for any program to access
any simple lossless compression, transparently.

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

What's this got to do with anything?

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

In file-as-a-directory (which is probably NOT happening soon), bar.zip
is both the actual zipfile and the view inside, depending on whether you
try to open() it directly or peek inside it as a directory.

I've used that interface for some simpler things like file permissions.
 I could do things like "echo 0 > some_file/metas/uid".  The interface
is gone for now, because it broke some things, I'm told, but nothing
serious for me while I was using it.  I don't think the problem is
insurmountable.

However, let's not discuss this now.  I do NOT want to start another
"silent semantic changes with reiser4" thread.  File-as-directory is not
happening this time, so don't worry about it -- this time.

> 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're misunderstanding.  man zip.
$ zip bar foo
creates/modifies a file named "bar.zip", not "bar", which contains the
file "foo".

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

Or, I can avoid those issues altogether, and simply delegate this kind
of stuff to user-created-but-magic directories.  For instance, I could
have a directory called "/foo" which contains encrypted files, and
"/foo/decrypted" which has transparently decrypted representations of them.

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

True, for now.  But for me, it's not hard at all to try "cp" first, and
after it fails, Google and install the required tool.  After all, most
users already have to do that with GUI interfaces, this just takes the
GUI way of doing things (like in file-roller) and makes it perform
better and work with all programs.  Not necessarily all formats, but all
programs.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQr8IzngHNmZLgCUhAQKS9A/+K+Nkq0sLynA0ltiA7o+BnA4cRSLYnu0t
LdVI+yvYMUocvZt1HcIuU1LN2y3//Xm7hh7Lsyf3moNCIFMkDUN/xuzUcmfpUs5W
NpyYPS4M3h8bX7nAMI9SmJ2KPoQNJxiEMToi5cYkQvafAeAlR2xw+z9nQ7Cv2PAi
PCKROYSbZ1MdyCVLDPYkIpk9Z9EnOZ7zE+nbMaippqAnwfoqMoe8OMBKt1qxBROS
tSPn4h1+JQZTs5OY18Cg/km7J6SM3SmHEWtsicil9/AVMFoOCpUXkeuiBLgVZ7Vk
hh79SLjmuAOgU5hTBhEwvtEjB5uGqbjRtp+quIWNO4tmHqPuSv+TP0YaOgMTqbf7
9Cr+iq/YrWMDCA3fYrnq/TiSCNK/YHGNlQG4rZtnKDXUFUZRuItMhbRaiYYfv/Cl
wQjBrknKci4xFNB9gIOoykS9Vs3JDdZc8oj26rFhHGqkGE+xo6b0z1EaZMvBfes9
L+VqU6B7YnyDWnhDbK6TiLZ/Qg83SigTyoLORVIDzyo3k2SVA8kmy8NgdA9NlmIT
ko/g0+7zHtu64LuEtQEdL/FULnI/YcMtxQDjYuhCqtUo/x4y3hi5685P00iZDfdp
RpuZnOT/esiw/RLashgGRK3xsVik9R+WX2psrEXp7HvNYvr5X4BpFovyVYeTxSnj
jV201bzTv6A=
=z+xB
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/