Re: [PATCH] ovl: add ioctls to retrieve layer file descriptors

Miklos Szeredi <[email protected]> writes:

> On Wed, 8 Jul 2026 at 17:55, Giuseppe Scrivano <[email protected]> wrote:
>>
>> Miklos Szeredi <[email protected]> writes:
>>
>> > On Wed, 8 Jul 2026 at 16:32, Giuseppe Scrivano <[email protected]> wrote:
>> >
>> >> 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/
>
> 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