Re: silent semantic changes with reiser4

[David Masover]

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

Christer Weinigel wrote:
| Spam <spam@xxxxxxxxxxxx> writes:
|
|
|>>When you add a new shared namespace, userspace must be taught about it
|>>anyways.  So start with a userspace library, convince people to use
|>>it, and when you know what people want, _then_ put it into the kernel
|>>to increase performance or security.
|>
|>  Several aspects of this;
|>
|>  1) Programs will need to actually be coded against this shared
|>  library which probably will be more advanced that just usning normal
|>  file access code.
|
|
| Not at all.  As many others have already shown, trying to use files as
| directories won't work since then you can't have named streams or
| attributes for real directories.  What does foo/icon refer to when foo

Oh yes, you can.  That's what "metas" is for.  I wanted to call it ...
| is a directory?  There must be some way of differentiating between

When foo is a directory, foo/icon is a normal file.  But foo/metas/icon
(or foo/.../icon if you like) is the metadata.

This already works.  I can use it right now for file permissions:

echo 755 > /bin/bash/metas/rwx
echo 755 > ./metas/rwx

| Besides, it will probably break a lot of security critical assumptions
| in todays software.  What if you have a filter in your web server that
| excludes executable files or files that end with .php, can you imagine
| the mess if you could just open "foo.php/main-stream" instead?

Why would you have a foo.php/main-stream?

And what would be so hard about allowing read access to foo, but not
access to foo's metas?  This is essentially the same as having mode 6 on
a directory.

[...]
|>  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,

What things?  It's just dangerously different thinking.  I don't see it
breaking anything on my system right now.  If anything, the nvidia
binary drivers are a bigger issue...

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

Yes, it is more useful than doing a userfs mount.  The userfs mount has
to be done manually or by a file manager.  I do not use a file manager.
~ I am not alone here.  Unless you're going to have the entire FS mounted
userfs and have that be the file manager, which wouldn't be nearly as
fast as plugins.

I've heard autofs mentioned -- which only works on specific files which
it's been preconfigured for.  Not good here.

| semantics (anymore than mount -o loop does today), and it will work
| with the existing infrastructure in the linux kernel.  The only

That's true -- it's easier to implement if you ignore the number of apps
which need patching.

There's also the fact that most people here won't be patching apps,
they'll just be breathing a sigh of relief that they didn't have to
patch the kernel.

Just because someone else has to do it doesn't make it any less work.

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

And this is a usability issue.  Not all newbies use Nautilus.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQTy3MngHNmZLgCUhAQJ/lQ//UmQOJLZAmsFFD8TJehD8WitMrImrcrBC
SJ/mCkIaPq5JNo9R/ovd1UoGlf47JUvaaT5G1d/yOMA+/0kPNqjJL49Km9A3Ze+C
00Uq12yP8yp6NjBzq9HKAjvyHVghl1A5ZllIdiwuc8Fywbl6UKUHlN1D4PpUp1uA
znKPjmGpBOsTzgNWJYbAfjns60C7DHZoD/S+ldt3af2PsJKOpx0v4fusV8Y2+XRG
kWybZLl1YPwPLfJLCaa3KpbY1KkSuk6TSeut90+zRV6s1WJ8LE98NpDBGUDt/+cm
AXcp/zyrUmbpvQtZBaUFYwZ8imizspiSHYnBwdhVm9tfERFOFI9diBidvanHk/s0
D+FSJhnQSeo/hMnbHlfv4E6p4k1jDvJk06XJ/U45sEym4hCp9roDPB0tUic7bOnE
mxNxzogp92KHfsVPuqkidq255ztAjRbzdnt8zsBOPImqTgfsO3xVfT3svIixNxWv
+qaAlrR7dAri9bi3wNLCjzRhp3id0fspetLJrrCHI/8hMlu7a6nsIHLocuvG069W
OzdXtTPRYsV8YlElsdL5d/3grZSL3CWNpQxoRb9gzj0hKHHPjrXw9ACcQthiknNc
DkjjcLxV2gPqhKq3WgMTKXHhLDWEfJpFVQ8PccJHsKaaUgGtDUg0ETBT54h8Mo8E
I0bkcYOLtHk=
=o3vQ
-----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/