[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJfpegvFsWyUsDcN7qQOEArc6WF9xre+gkC_kjgbyXPBHM84kQ@mail.gmail.com>
Date: Tue, 13 May 2025 16:49:03 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: Christian Brauner <brauner@...nel.org>
Cc: Amir Goldstein <amir73il@...il.com>, Chen Linxuan <chenlinxuan@...ontech.com>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/3] fs: fuse: add backing_files control file
On Tue, 13 May 2025 at 09:57, Miklos Szeredi <miklos@...redi.hu> wrote:
>
> On Tue, 13 May 2025 at 09:39, Christian Brauner <brauner@...nel.org> 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@mail.gmail.com/
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
Powered by blists - more mailing lists