On Sat, Oct 12, 2024 at 10:25:38AM +0200, Amir Goldstein wrote:
> On Fri, Oct 11, 2024 at 11:46 PM Christian Brauner <brauner@xxxxxxxxxx> wrote:
> >
>
> nit: if you can avoid using the exact same title for the cover letter and
> a patch that would be nice (gmail client collapses them together).
Fine, but fwiw, the solution to this problem is to use a proper email
client. ;)
>
> > Currently overlayfs only allows specifying layers through path names.
> > This is inconvenient for users such as systemd that want to assemble an
> > overlayfs mount purely based on file descriptors.
> >
> > This enables user to specify both:
> >
> > fsconfig(fd_overlay, FSCONFIG_SET_FD, "upperdir+", NULL, fd_upper);
> > fsconfig(fd_overlay, FSCONFIG_SET_FD, "workdir+", NULL, fd_work);
> > fsconfig(fd_overlay, FSCONFIG_SET_FD, "lowerdir+", NULL, fd_lower1);
> > fsconfig(fd_overlay, FSCONFIG_SET_FD, "lowerdir+", NULL, fd_lower2);
> >
> > in addition to:
> >
> > fsconfig(fd_overlay, FSCONFIG_SET_STRING, "upperdir+", "/upper", 0);
> > fsconfig(fd_overlay, FSCONFIG_SET_STRING, "workdir+", "/work", 0);
> > fsconfig(fd_overlay, FSCONFIG_SET_STRING, "lowerdir+", "/lower1", 0);
> > fsconfig(fd_overlay, FSCONFIG_SET_STRING, "lowerdir+", "/lower2", 0);
> >
>
> Please add a minimal example with FSCONFIG_SET_FD to overlayfs.rst.
> I am not looking for a user manual, just one example to complement the
> FSCONFIG_SET_STRING examples.
>
> I don't mind adding config types on a per need basis, but out of curiosity
> do you think the need will arise to support FSCONFIG_SET_PATH{,_EMPTY}
> in the future? It is going to be any more challenging than just adding
> support for
> just FSCONFIG_SET_FD?
This could also be made to work rather easily but I wouldn't know why we
would want to add it. The current overlayfs FSCONFIG_SET_STRING variant
is mostly equivalent. Imho, it's a lot saner to let userspace do the
required open via regular openat{2}() and then use FSCONFIG_SET_FD, then
force *at() based semantics down into the filesystem via fsconfig().
U_PATH{_EMPTY} is unused and we could probably also get rid of it.
>
> Again, not asking you to do extra work for a feature that no user asked for.
>
> Other than that, it looks very nice and useful.
Thanks!
