>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:

[...]

Linus> This is why I want to have stronger reasons for real VFS
Linus> support. I see the Samba argument, and I buy that one, if only
Linus> because it has such a high consistency requirement (let's face
Linus> it, people expect more guarantees of their file servers than of
Linus> most other things). But on the other hand, the Samba guys
Linus> apparently _are_ happy with "openat()", so they don't necessarily
Linus> need any normal namespace stuff.

Maybe things have got lost in this thread (or these many threads), so
bear with me, but what exactly does openat() gain us that we can't get
from exporting things from the normal file namespace?  The only issue
that I've seen raised is that you need to be able to distinguish between
the contents of a directory and its substreams.  And I've responded that
streams should be stuck in a specially-named subdirectory (like
..streams) (which should be done even if only files could contain
substreams), to which I have seen no objections raised (not even as much
as a "you're stupid"), and so can only assume nobody (who cares) has any
objections.

So as far as I can see, openat() has no advantages, and exporting
things through the normal namespace has several advantages, such as:
- can manipulate substreams using legacy programs -- no modifications
  needed.  And don't tell me "runat" until someone shows me how to deal
  with my GIMP/emacs problem.
- useful for exporting different things (streams, acl's or other access
  control schemes, xattrs, version control, automatic untar, ...)
- only need to modify tar (and backup programs) once -- any new
  filesystem extensions, no matter how complex, can be exported through
  the filesystem interface, and tar will be able to catch them.
- referring to the substreams is simpler ("foo.txt/streams/bar"
  instead of "the bar stream of foo.txt"), which leads to simpler user
  interface.  This is even more marked if we, for some strange reason,
  discover that it's a good idea for streams to be allowed to have
  substreams of their own ("foo.txt/streams/bar/streams/baz" vs. "the
  baz stream of the bar stream of foo.txt")
- I think I'm forgetting some...

If this is indeed the case, then it seems to me that the logical choice
is to export streams through the normal file namespace.

-- 
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.