Re: silent semantic changes with reiser4

Linus Torvalds
2004-08-30T03:57:17Z

On Mon, 30 Aug 2004 viro@parcelfarce.linux.theplanet.co.uk wrote:
> >
> > So I don't see any way to extend pathname semantics to distinguish between
> > "directory contents" and "directory attribute stream".
>
> I do, actually. There might be a way and it is kinda-sorta similar to
> your openat() variant, but lives in normal namespace. No, I'm not too
> fond of that, but since we are discussing weird variants anyway...
>
> a) associated directory tree of object is not automounted on top
> of it. Instead of that, we always do detached vfsmount (and do it on demand -
> see below)
> b) we have a bunch of pseudo-symlinks in /proc/<pid>/fd/ - same
> kind as what we already have there, but instead of (file->f_vfsmount,
> file->f_dentry) they lead to associated vfsmount (allocated if needed).
> Once we get a reference to such guy, we can
> * do further lookups
> * chdir there and poke around
> * hell, we can even bind it someplace (that will require slight change
> in attach_mnt() logics, but it's not hard) and get it permanently mounted

Well, the above _is_ the same as "openat()", really. It's just using a
filesystem starting point to emulate a new system call. Same thing
conceptually. You could do pretty much any system call as a filesystem
action if you wanted to ;)

I don't disagree with doing so - as a way to expose the new system call to
scripts. But I don't think you're being entirely intellectually honest if
you think this suddendly makes it be "one namespace". It's still a
secondary namespace rooted in an entry in the normal ones - exactly like
"openat()".

For a non-script, a native "openat()" interface would be more efficient
and less confusing, and conceptually no different from yours. No reason
we couldn't have both, since they are 100% equivalent and would share the
same code anyway...

Linus