On Tue, Aug 11, 2020 at 09:05:22AM -0700, Linus Torvalds wrote: > On Tue, Aug 11, 2020 at 8:30 AM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > > > What's the disadvantage of doing it with a single lookup WITH an enabling flag? > > > > It's definitely not going to break anything, so no backward > > compatibility issues whatsoever. > > No backwards compatibility issues for existing programs, no. > > But your suggestion is fundamentally ambiguous, and you most > definitely *can* hit that if people start using this in new programs. > > Where does that "unified" pathname come from? It will be generated > from "base filename + metadata name" in user space, and > > (a) the base filename might have double or triple slashes in it for > whatever reasons. > > This is not some "made-up gotcha" thing - I see double slashes *all* > the time when we have things like Makefiles doing > > srctree=../../src/ > > and then people do "$(srctree)/". If you haven't seen that kind of > pattern where the pathname has two (or sometimes more!) slashes in the > middle, you've led a very sheltered life. > > (b) even if the new user space were to think about that, and remove > those (hah! when have you ever seen user space do that?), as Al > mentioned, the user *filesystem* might have pathnames with double > slashes as part of symlinks. > > So now we'd have to make sure that when we traverse symlinks, that > O_ALT gets cleared. Which means that it's not a unified namespace > after all, because you can't make symlinks point to metadata. > > Or we'd retroactively change the semantics of a symlink, and that _is_ > a backwards compatibility issue. Not with old software, no, but it > changes the meaning of old symlinks! > > So no, I don't think a unified namespace ends up working. > > And I say that as somebody who actually loves the concept. Ask Al: I > have a few times pushed for "let's allow directory behavior on regular > files", so that you could do things like a tar-filesystem, and access > the contents of a tar-file by just doing > > cat my-file.tar/inside/the/archive.c > > or similar. > > Al has convinced me it's a horrible idea (and there you have a > non-ambiguous marker: the slash at the end of a pathname that > otherwise looks and acts as a non-directory) > Putting my kernel hat down, putting my userspace hat on. I'm looking at this from a potential user of this interface. I'm not a huge fan of the metadata fd approach I'd much rather have a dedicated system call rather than opening a side-channel metadata fd that I can read binary data from. Maybe I'm alone in this but I was under the impression that other users including Ian, Lennart, and Karel have said on-list in some form that they would prefer this approach. There are even patches for systemd and libmount, I thought? But if we want to go down a completely different route then I'd prefer if this metadata fd with "special semantics" did not in any way alter the meaning of regular paths. This has the potential to cause a lot of churn for userspace. I think having to play concatenation games in shared libraries for mount information is a bad plan in addition to all the issues you raised here. Christian
