On Mon, 2024-11-11 at 11:49 +0100, Miklos Szeredi wrote: > On Thu, 7 Nov 2024 at 22:00, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > > + /* > > + * If nothing was emitted, return to avoid setting the flag > > + * and terminating the buffer. > > + */ > > + if (seq->count == start) > > + return ret; > > First of all, I don't think it's okay to subtly change behavior of > other string attributes in this patch. If that is what we want, it > should be separated into a separate prep or followup patch. > 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. > Clearing the returned mask if there's no subtype does sound like the > right thing to do. But it makes it impossible to detect whether the > running kernel supports returning subtype or not. Missing the > STATMOUNT_FS_SUBTYPE in statmount.mask may mean two different things: > > - kernel supports returning subtype and filesystem does not have a subtype > > - kernel does not support returning a subtype and the filesystem may > or may not have a subtype > > I think we can live with that, but it would be really good if there > was a universal way to detect whether a particular feature is > supported on the running kernel or not, and not have to rely on > syscall specific ways. 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. 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. -- Jeff Layton <jlayton@xxxxxxxxxx>
