Re: silent semantic changes with reiser4

[Spam]

>>   Plugins were just another thing that could extend the functionality
>>   of these streams and meta data. Reiser4 has a plugin architecture,
>>   although not yet any run-time support for loading them. Is this so
>>   bad that we have to prevent it?

> Take an example: "expose a tar-file as streams below the file" which
> as been suggested here is IMNSHO plain silly.  I'm not saying anything
> about mounting a tar file via userfs somewhere else in the file
> system, that is quite ok, but trying to mount it on top of the same
> file which suddenly and automagically turns into a sort-of-directory
> breaks too many thing.  Let your file manager do the choice instead,
> based on the users preferences.  For example, with a tar.gz-file, I'd
> like to have a choice of "open file as a seekable file" which would
> do:

>     mount -t userfs -o driver=gunzip foo.tar.gz /tmp/xyzzy

 Where is the difference? Both would be handled by a specific driver
 or module and export the same semantics (files+dirs) with permissions
 etc to the user. With your idea you still would need the userfs
 kernel module, and with "magic plugins", as you said, you will need a
 vfs/reiser4 kernel plugin.

> Then I can work with /tmp/xyzzy as a normal file (maybe even with
> write access if the userfs driver can handle this).  Another choice in
> the same file manager would be "open file as a directory" which would
> mount the same file in _another place_ as a directory, and I can even
> have different views of the same file mounted at the same time.  With
> the named streams junk that have been suggested here, having two
> different views would be impossible.

> Sure, we could say that we add another level of indirection to the
> named streams, so that we specify the driver as the first component of
> te magic file-as-directory, i.e. foo.tar.gz/ungzipped would refer to
> the ungzipped stream and foo.tar.gz/ungzipped-and-untarred would show
> the tar file as a directory, but really, this isn't any more useful
> than doing a userfs mount.  The userfs mount does not break existing
> semantics (anymore than mount -o loop does today), and it will work
> with the existing infrastructure in the linux kernel.  The only
> advantage of files-as-directories with magic plugins in the kernel is
> that one can look at it and say "look, how neat, the filenames look
> almost the same".

  No there are _usability_ differences. I cirtanly do not want to
  mount lots of files with mount -t userfs, just to see extra
  meta-data that I want to quickly be able to use. And it also
  wouldn't work generically (searchable) with tools like find, grep,
  etc either.

  ~S

>   /Christer


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