On Tue, 2020-08-11 at 21:39 +0200, Christian Brauner wrote: > 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? Not quite sure what you mean here. Karel (with some contributions by me) has implemented the interfaces for David's mount notifications and fsinfo() call in libmount. We still have a little more to do on that. I also have a systemd implementation that uses these libmount features for mount table handling that works quite well, with a couple more things to do to complete it, that Lennart has done an initial review for. It's no secret that I don't like the proc file system in general but it is really useful for many things, that's just the way it is. Ian
