Re: [PATCH v3 1/2] fs: add the ability for statmount() to report the fs_subtype

[Jeff Layton]

On Mon, 2024-11-11 at 14:01 +0100, Miklos Szeredi wrote:
> On Mon, 11 Nov 2024 at 12:28, Jeff Layton <jlayton@xxxxxxxxxx> wrote:
> 
> > As far as I can tell, the existing cases in statmount_string() either
> > always emit a string or an error code. If a string isn't emitted, then
> > the two EOVERFLOW cases and the EAGAIN case can't happen, so I don't
> > think this will result in any change in behavior for the existing code.
> 
> Both mnt_point and mnt_opts can be empty.
> 

Ok, so currently if they are, the flag gets set and there is no
string?  If so, then you're correct and this is a behavior change. The
question is -- is it a desirable one? The interface is new enough that
I think we have the luxury of changing this now (and establishing a
future standard).

Personally, I think that's how it ought to work. When there is no
string present, we ought not set the flag in the return mask. Does
anyone prefer it the other way?

> > The idea for statmount() was to add a statx() like interface. This is
> > exactly how statx() works, so I don't think it ought to be any sort of
> > surprise to anyone.
> 
> Maybe, but silently changing the interface is not okay.  At least make
> it a separate patch.
> 

Ok, Christian has already taken this in, but I can respin it and 
split that bit out into a separate patch. Or, I could just revise the
changelog to note the behavior change.

Either way, we'll need to decide about how empty fields should be
handled first.

> > That said, if we did want to add a way to detect what flags are
> > actually supported, we could just add a new STATMOUNT_SUPPORTED_FLAGS
> > flag and add a field that holds a returned mask with all of the bits
> > set that the kernel supports.
> 
> Yeah, that makes sense.
> 

-- 
Jeff Layton <jlayton@xxxxxxxxxx>