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>
