On Mon, Apr 15, 2024 at 6:59 PM Eric Sandeen <sandeen@xxxxxxxxxx> wrote: > > In case this is of interest to anyone I'll propose it. > > The "new" mount API was merged about 5 years ago, but not all filesystems > were converted, so we still have the legacy helpers in place. There has been > a slow trickle of conversions, with a renewed interest in completing this > task. > > The remaining conversions are of varying complexity (bcachefs might > be "fun!") but other questions remain around how userspace expects to use > the informational messages the API provides, what types of messages those > should be, and whether those messages should also go to the kernel dmesg. > Last I checked, userspace is not yet doing anything with those messages, > so any inconsistencies probably aren't yet apparent. > > There's also the remaining task of getting the man pages completed. > > There were also some recent questions and suggestions about how to handle > unknown mount options, see Miklos' FSOPEN_REJECT_UNKNOWN suggestion. [1] > > I'm not sure if this warrants a full session, as it's actually quite > an old topic. If nothing else, a BOF for those interested might be > worthwhile. > Christian, I scheduled a slot for your talk on "Mount API extensions" on Tue 11:30 before Eric's Mount API conversions session. Do you think this is the right order or do you prefer these sessions to be swapped? Also, this seems like a large topic, so I could try to clear more than 30min in the schedule for it if you like. the buffer_heads session after your talks will probably be removed from there anyway. I was thinking that we need a followup session for statmount/listmount [1] What's still missing (mount change notifications, fsinfo) and what are the next steps. Are you planning to address those in your session? Thanks, Amir. [1] https://lore.kernel.org/linux-fsdevel/20240105-vfs-mount-5e94596bd1d1@brauner/
