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. > 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. > 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. Thanks, Miklos
