Messages in this thread | | | Date | Mon, 30 Aug 2004 10:58:54 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: silent semantic changes with reiser4 |
| |
On Mon, 30 Aug 2004, Paul Stewart wrote: > > Here's another take on the same theme. To see attrs on files, one can > either use a newly developed application which can use special new > syscalls/flags on syscalls a Paul Jackson recommends. However from an > old shell or application one can also open the attribute node on > /home/myself/foo.txt by checking out /attr/home/myself/foo.txt/, which > points to the "as directory" node on the filesystem that foo.txt points > to.
This is the same idea as Al Viro's /proc/self/fd/#42/attr issue, except yours has two fundamental problem: races and ambiguities.
If you open a filename in some "secondary" tree (be it /proc or //attr or whatever) based on the filename in the primary one, you have two issues that you need to work out:
- how do you handle a name change in the primary tree at the same time as lookup - how do you handle the ambiguity of //attr/usr/bin/emacs/icon (is that the "icon" attribute on "/usr/bin/emacs", or is it perhaps the "emacs/icon" attribute on "/usr/bin").
The ambiguity can be handled by saying that attributes only have one component (ie only the _last_ component of a lookup is the attribute name). But the race between primary tree and secondary tree cannot be handled in a normal name-space.
What Al did was to avoid both by "fixing" the attribute lookup point with another open - _exactly_ the same way "openat()" handles it. So Al's naming convention avoids both the ambiguity and the primary tree name change races by first opening the primary tree file, and then explicitly using that file as the "anchor" in the secondary tree. He did it in /proc, where we obviously already do export an open fd as an anchor-point.
> The strange part of this idea is that the /attr filesystem wouldn't be > conventionally browsable.
That may make it non-intuitive to use, but that's not the real problem. See above.
Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |