On Wed, 2019-05-22 at 15:55 +0200, Karel Zak wrote: > On Wed, May 22, 2019 at 09:14:37PM +0800, Ian Kent wrote: > > On Tue, 2019-05-21 at 21:28 -0700, L A Walsh wrote: > > > On 2019/05/21 19:59, Ian Kent wrote: > > > > I hadn't planned on producing a utility but I do have code that I've > > > > been using to learn how to use the call. > > > > > > > > I could turn that into a utility for use from scripts at some point. > > > > > > > > > > --- > > > not required, but thought it might allow for more types of > > > tests/usages. > > > If it is really of limited or no benefit, I'm not gonna lose sleep. > > > > Avoiding having to parse string output (from the proc file system > > > > mount tables) is one of the key reasons to use a system call for > > > > this. > > > > > > > > So this isn't the point of doing it. > > > > > > > > > > I get that....this wasn't intended as an 'endpoint' just a way for those > > > not > > > implementing and using the calls to get a feel for the call. It may > > > not serve > > > a useful purpose in this case, but some system calls have direct > > > user-utils that > > > are very useful. The lack of a system util to manipulate the pty calls > > > forced > > > me to write a few-line 'C' prog just to make 1 call to approve > > > something. Eventually switched to a more robust interface in perl. > > > > We will see, I will end up with something that's more or less example > > usage anyway. > > I'd like to write something like "mountsh" one day. The idea is to > have very low-level tool that is able to provide command line > interface to the all fragments of the new mount API in the same > granularity as provided by kernel (mount(8) is too high-level in this > case). There's fairly simple example usage of several of the mount-api calls in samples/vfs/test-fsmount.c. There's the in kernel mount-api documentation at Documentation/filesystems/mount_api.txt although that's more oriented to usage within the kerenl. I was wondering if kernel file systems that have not been converted to use the new api (but use the legacy mount-api kernel code) will work properly with the new mount-api? I think they would have to for the mount-api to be viable but I'm not sure. LOL, I remember, all those years ago, when you set out to write libmount and I wanted to convert autofs to use it. Sadly I got swamped with other work and ended up more concerned about eliminating proc mount table usage wherever possible in autofs but with the fsinfo() and mpount-api changes I should be able to change autofs to use libmount. After all these years I'll finally be able to get meaningful error codes that I simply can't get from mount(8) or mount.nfs(8). The autofs kernel module has been capable of passing these back to user space for years now and there shouldn't be too many autofs user space changes needed. But there's a lot of work to be done on libmount and we absolutely must keep libmount stable all the way so it's a big challenge. > > Anyway, the primary goal is to use the new syscalls on standard > places (e.g. libmount) where it improves performance. > > > > I.e. why not subdirs for 'by-mountpoint', or by-device, or > > > whole-dev-vs.partition, or by UUID....like some things are listed > > > in /dev. That would allow you to narrow in on the mount you want for > > > doing whatever. > > > > TBH, I can't see that amount of code being added to the VFS > > for this. > > > > Simple annoyances like some mounts won't have a UUID, or won't > > have partition devices associated with them will also cause > > inconsistent views of the mounts. > > or more filesystems mounted on the same mountpoint, mountpoint is > deleted, etc... > > Karel >
