Re: silent semantic changes with reiser4

From: Helge Hafting
Date: Mon Aug 30 2004 - 08:55:58 EST

Linus Torvalds wrote:

On Sat, 28 Aug 2004, Helge Hafting wrote:


I think that lack of distinguishing power is more serious for directories. The more I think I think about it, the more I wonder whether Solaris did things right - having a special operation to "cross the boundary".

I suspect Solaris did it that way because it's a hell of a lot easier to do it like that, but regardless, it would solve the issue of real directories having both real children _and_ the "extra streams".


There are many ways of doing this. Several extra streams to a directory
that aren't ordinary files in the directory?



Well.. Yes. We already have "." and "..", which are "special extra
streams" in a sense. However, people expect them, and know to ignore them. The same wouldn't be true of new naming.



It seems to me that we can get a lot of nice functionality in a simpler way:
Instead of thinking about a number of streams attached to something
that is either an ordinary file or directory, just say that the only
change will be that a directory may have a _single_ file stream in
addition to being a plain directory.



That doesn't really help us. What would the name be, and how could you avoid clashes?

The name for the file stream and the directory would be the same,
distinguished by how they're used. I.e. fopen("filedirname", "rw")
gets the stream, while chdir("filedirname") changes into the directory.
fopen("filedirname/substream", "rw"); opens some stream inside
the directory - as usual.

My idea is that the "extra streams" aren't special at all, they
are simply files in a directory and will therefore work with
any normal tool. cd'ing into such a directory won't be special
either - because it is a plain directory. A collection of named streams
is usually a bunch of files in a directory - nothing new there.

Someone serving files for clients using
other os'es may attach special meaning to them, but I don't see the need
for a special meaning under linux.

So the only new thing is that the directory have a stream of
its own. Then there must be a way to turn a ordinary
file into such a directory - people may then implement
thumbnails, summaries and so on as substreams. Where
the substreams really are plain files in this slightly
special directory.

Perhaps mkdir with an existing filename could succeed,
creating a mixed file/directory, if the underlying fs support it.



If the VFS is to be extended in order to support file-as-directory (or
vice versa) then hopefully it can be done in a simple way.



I'm pretty confident that we can extend the VFS layer to support named
streams (see the technical discussion with Al, rather than the flames in
this thread). I also clearly believe that it is worth it, but I'm starting
to wonder if we should have a special open flag to make people select the
stream.

If you look at the Solaris interface, the _nice_ part about "openat()" is that you can do something like

file = open(filename, O_RDONLY);
if (file < 0)
return -ENOENT;
icon = openat(file, "icon", O_RDONLY | O_XATTR);
if (icon < 0)
icon = default_icon_file;
..

and it will work regardless of whether "filename" is a directory or a regular file, if I've understood correctly.


An alternative: support open("filename/icon", O_CREAT);
and have this turn "filename" into file-as-directory if it wasn't so
already. Then it works both with files and directories.
A new flag might be needed if old programs somehow depend on the stuff
above failing for plain files.

Now, I think that makes sense for several reasons:
- single case
- race-free (think "stat()" vs "fstat()" races).
- I think we want to do "openat()" regardless of whether we ever support extended attributes or not ("openat()" is nice for doing "namei()" in user space even in the absense of any attributes or named streams).

So what we can do is
- implement openat() regardless, and expect to do the Solaris thing for it if we ever do streams.
- _also_ support the "implied named attributes" for regular files, so that you don't have to use "openat()" to access them.

Comments? Does anybody hate "openat()" for any reason (regardless of attributes)? We can easily support it, we'd just need to pass in the file to use as part of the "nameidata" thing or add an argument (it would also possibly be cleaner if we made "fs->pwd" be a "struct file").



No problem with openat()

Helge Hafting

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