On Wed, May 28, 2025 at 01:47:37PM +0200, Miklos Szeredi wrote:
> On Wed, 28 May 2025 at 12:55, Karel Zak <kzak@xxxxxxxxxx> wrote:
>
> > Why is it fine for mount(2) but wrong for fsconfig()? This is the
> > question. There is an incompatibility between the APIs.
>
> Where is it documented that the fsconfig(2) shall have the same
> replace semantics as mount(2)?
Okay, fair enough, but you understand that userspace needs to adapt to
the new API, and ideally, changes should not be introduced to
end-users.
Frankly, I already have a private TODO file for libmount2 because I
feel we need to move forward, simplify things, move away from the
mount(2) syscall, and fully adapt to the new kernel API, which
provides features we do not yet support on the command line. The
current mount(8) command line and semantics are based on the mount(2)
era. The remount with all the obscure options (like MS_REMOUNT|MS_BIND)
is the worst legacy.
> I think this is just a bad accident, and I'm wondering if this could
> still be fixed in a way that doesn't introduce more hackery.
Why can't filesystems silently ignore fsconfig() requests that do not
introduce a change? For example, if the current setting is foo=123 and
fsconfig() is used to change it to foo=123, why is it reported as an
error? It's stupid, but just no op.
> One idea is to introduce a flag (e.g. FSPICK_REPLACE_ONLY) that makes
> the filesystem initialize the fs_context with the current options.
> That would work, no?
I'm not sure I understand how it will affect userspace. Do you mean
that with the flag, the kernel will assume a completely new set of
options from userspace, and the filesystem will adapt (if possible) to
the new settings?
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
