Re: The argument for fs assistance in handling archives

[David Masover <ninja@slaphack.com>]

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

Stephan von Krawczynski wrote:
| On Fri, 03 Sep 2004 19:13:31 -0500
| David Masover <ninja@slaphack.com> wrote:
|
|
|>| Just choose the right program.  tar groks tar files, not ls.
|>
|>tar groks tar.  bzip2 groks bz2.  gzip groks gz.  "mount -o loop" groks
|>images.  zip groks zip.  rar groks rar.  openoffice groks .sxw, unless
|>staroffice does.  xmms can read id3 info from mp3s.  gcc compiles C.
|>
|>If the file is an object, it's easier.  You can ask the file what it is,
|>and what you can do with it.  And you can tell it to do certain standard
|>things.  You can do all of this while reading almost no documentation on
|>what the file is.  At the end of the day, it won't matter to you whether
|>a file is zip, rar, or tar -- it's an archive, and you can extract it by
|>copying files out of its /contents directory.
|>
|>Your way (the traditional way) means you have to learn to use which
|>program is the right program and how to use that program, and you'll
|>have to remember it constantly.
|
|
| Just a short input from someone listening quite a while to this thread:
| I think your approach to the problem leads actually nowhere. The
reason for
| this is implicit in your own explanation. _Currently_ you talk of
archives, but
| as soon as you got that, what's next?

Anything sane.  Currently I talk of archives, because I need examples,
and archives have been a good example for awhile of something that can
gain things from plugins which they cannot get anywhere else, which have
implications immediately after the archive plugin is wrote, without
requiring any application support.

| Your idea needs abstraction, then you see the problem more clearly:
| An archive is only some sort of file type, just as (you already named)
mp3 or
| .sxw is another type. If you really want to do something _generally_
useful you
| should think of a method to parse and use all kinds of filetypes and
create an
| interface for that.

Fine.  It'd certainly be nice to use vim to edit an id3 tag, or a text
portion of a .sxw document (openoffice is HUGE compared to vim).

| And one thing is clear: as there are numerous different types you
cannot pull
| all that code inside the kernel. Obviously there should be a way some

I never said it should all go in the kernel.  I repeatedly said that
most of it should not -- all that goes in the kernel is the most generic
interface that is sane.  Obviously an archive plugin is different than a
compression plugin, but once you've got the archive plugin, the rest
(individual format support) can go in userland.

| application can install a hook, a helper, a plugin or whatever to provide
| extended functionality on its special filetypes. If you don't want to
use tar,
| you don't need the plugin either.

So you disable it at compile time.  I don't want to use XFS, and I
certainly don't want to use ATI's video drivers.  The latter I choose
not to download, and the former I choose not to activate.

| If you want tar, you should (as a user) be able to install the "fs-plugin"

If by "as a user" you mean "not root", I have to disagree.  I think it'd
have security implications.  It'd be great if I'm wrong.

| (just a name, do not shoot me for it) together with tar as an
application. You
| get the idea? Obviously this must be possible during runtime,
everything else
| is senseless.

I would love for this same attitude of "runtime or bust" to be more
common.  I would love for there to be a generic way to write a userland
fs plugin, just as there's a generic way to write a userland filesystem
(lufs).  Just understand that some plugins will be in userland, and some
will be in the kernel.

And, in fact, the part of the archive plugin that knows about
tar/zip/rar/whatever goes in userspace.  But the part that does caching
probably goes in kernel space, even if it becomes a more generic
"caching plugin".

| So, please, if you go on investigating this whole stuff do it in a
more general
| way, because "tar inside kernel" is not really what your idea is all
about, no?

Absolutely not.

| And one last obvious thing: if one doesn't want this kind of
file-handling, he
| should not need it. It has to be an add-on functionality, not a
replacement.

For awhile, yes.  But I can imagine that sometime in the future, an app
would need this kind of functionality.  And why not?  Is it so much
worse for an app to insist on "mp3 metadata plugin" than to insist on
"libid3"?

In any case, look at the current implementation.  I can do
	echo 750 > file/metas/rwx
but I can also use chmod, which is currently much more efficient.  I
think Hans wants to eventually create an efficient interface to access
lots of small files at once (or maybe this is done?) -- and his dream is
to see things like chmod replaced with a call to this interface.  But at
best, chmod will become a library call sometime years from now.  It will
never go away entirely.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQToI+3gHNmZLgCUhAQKEWg/9F0FZGxB2yXoo9l5UKI7Fvh19RlnpJvZE
D3DajNqxXZ5smYIba7QxATEwMLWNMwOdiJTDIcQ7jylbD3hTkp0uFQLXcS5FeWt5
yxA0oDYEHsW14aQov4pHGplHVvCHSkm6vJn/zU91QdJAZVYnH4na5NFuWsAIoUWi
5vigYTefavabFv0/RnyPCN6zFfn3hrjOnKqSELUXXleG/fV+XJVw3Nyg4DSe1hK+
xmXHFWkGC832tH052EH/CFlE17/K05QdpfBKYNzCFA5dvTtCs11OQZSggtGVipmn
cSycyDHtJraMdF78Qa8LZzjGiZbT/3befM6wrnekcwhjxCqok8CSbOvbVh2ENtiu
klNtHeQEEtm+4MhbEEkdiiuWaU7EHIFJFGYC6LJE0B4DAKDdi4TM9QbqxLW8HghQ
WUJfMh8H2FtqotjMsdDW0OCmSuzh0B4ZZ9EXvSMIttXBJ7T2+q442hm4PAFQWXSO
FPCAiUgGZ+ZCbyZI1/pjM+CGblMTCfCBOm8UI3MSjTTI7cVzWFrQHJSAUhCPIsxA
9RZlEvmg+ElbnGrJkpDggpToDFN5uHXj41r4CZBnXgjfUdA0jmHnWpzO29Smfu7i
cJPtN+LzR1Se+fz4IvYamWd1p/Mi3vQACPt4r3IGVKa27tYXzDw+CNa+CliHnczt
lAhISMnhoVo=
=7rV6
-----END PGP SIGNATURE-----