Miklos Szeredi [off-list ref] writes:

On Wed, 8 Jul 2026 at 17:55, Giuseppe Scrivano [off-list ref] wrote:

quoted

Miklos Szeredi [off-list ref] writes:

quoted

On Wed, 8 Jul 2026 at 16:32, Giuseppe Scrivano [off-list ref] wrote:

quoted

Amir suggested to add that functionality when I've asked for some
feedback before sending the patch here.  I am fine to drop it if this is
the consensus although I see its utility from user space.

How about a completely different interface:

int get_fd_opt(const char *name, unsigned int index, unsigned int flags);

Enumerating layers would be as easy as passing an index stating from
zero and stopping when -ERANGE is received.

It would work for all filesystems that use files as options.  No more
fs specific ioctls.

Is a new syscall really justified for such a narrow use case?

That's the reason I advocate pseudo fs based solutions.  Let's see, we
had a proposal to use openat(), something. like:

openat(base_fd, "mount/options/lowerdir+/0", O_ALT | O_PATH);

Meaning that O_ALT switches to an alternative/meta namespace that is
based on the given fd and in that meta namespace the tree under mount/
represents the attributes of the mount that base_fd is on.

See this post from Linus as well:

  https://lore.kernel.org/all/CAHk-=wjzLmMRf=QG-n+1HnxWCx4KTQn9+OhVvUSJ=ZCQd6Y1WA@mail.gmail.com/ (local)

The statmount api took a different route, but for getting an O_PATH
file this would be a very natural interface without added syscalls.

I don't argue against such an API, I only argue that I am probably not
the best person to drive such a significant change :-)

Would you be OK with the ioctl as a solution that works today, and
duplicate it when an alternative API materializes?

Thanks,
Giuseppe