On Tue, 13 May 2025 at 09:57, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Tue, 13 May 2025 at 09:39, Christian Brauner <brauner@xxxxxxxxxx> wrote: > > The xattr system call as far as I'm concerned is not going to be pimped > > to support stuff like that. > > Heh? IIRC there were positive reactions to e.g. "O_XATTR", it just > didn't get implemented. Can try to dig this up from the archives. Here it is: https://lore.kernel.org/all/CAHk-=wjzLmMRf=QG-n+1HnxWCx4KTQn9+OhVvUSJ=ZCQd6Y1WA@xxxxxxxxxxxxxx/ Quoting Linus inline: | IOW, if you do something more along the lines of | | fd = open(""foo/bar", O_PATH); | metadatafd = openat(fd, "metadataname", O_ALT); | | it might be workable. | | So you couldn't do it with _one_ pathname, because that is always | fundamentally going to hit pathname lookup rules. | | But if you start a new path lookup with new rules, that's fine. | | This is what I think xattrs should always have done, because they are | broken garbage. | | In fact, if we do it right, I think we could have "getxattr()" be 100% | equivalent to (modulo all the error handling that this doesn't do, of | course): | | ssize_t getxattr(const char *path, const char *name, | void *value, size_t size) | { | int fd, attrfd; | | fd = open(path, O_PATH); | attrfd = openat(fd, name, O_ALT); | close(fd); | read(attrfd, value, size); | close(attrfd); | } | | and you'd still use getxattr() and friends as a shorthand (and for | POSIX compatibility), but internally in the kernel we'd have a | interface around that "xattrs are just file handles" model. | | Linus
