Re: [RFC PATCH] fs: allow opening overlayfs/erofs layers through O_ALT

quoted

And the smaller details really show how inelegant this model is and why
Al and I have opposed it multiple times before. Scalar options are
modeled as symlinks and non-path options are dangling links whose
readlink still returns the value while for path options readlink returns
the option string but following the link jumps somewhere else entirely.

Hey, this is was a prototype to show that this can do what Giuseppe
needs.  Not with nicely polished interfaces.

I want to do a sidebar regarding "what Giuseppe needs".

As I wrote I am all for introspection of overlayfs layers, but I was never
fully convinced that getting an open fd was the correct API.

The starting point of the use case is a userspace daemon that wants
to reuse mounted erofs images, which are used as lower layers.

When considering a single daemon (e.g. composefs) this reuse
would be better done completely in userspace without kernel involvement.

The reason for a need for kernel UAPI for introspection of layers was
to allow cross daemon optimizations, so that containerd could reuse
erofs images mounted by composefs.

This optimization works under the assumption that the image file
or the image file hash is a unique identifier of the desired lower layer.

But what if composefs mounted the image with idmapping or some other
property?

And how many container runtimes are there out there?
Is it really worth the elaborate effort to provide introspection
to this level?

My intuition is that introspection should provide static information
like uuid/fsid/fhandle rather than an open fd.

I am willing to be convinced otherwise with the proper arguments.

Thanks,
Amir.