Re: proposed libc interface and man page for statmount(2)

[Ian Kent <ikent@redhat.com>]

On 22/11/23 04:42, Zack Weinberg wrote:
> On Tue, Nov 21, 2023, at 2:42 PM, Miklos Szeredi wrote:
>> handle = listmount_open(mnt_id, flags);
>> for (;;) {
>>      child_id = listmount_next(handle);
>>      if (child_id == 0)
>>          break;
>>      /* do something with child_id */
>> }
>> listmount_close(handle)
> Why can't these be plain old open, read, and close? Starting from a pathname in /proc or /sys. Doesn't allow lseek.

I'm not sure how this would work, there aren't a series of paths in proc

that represent mounts?


There are a couple of reasons for not creating a tree of directories

to represent mounts in the proc file system.


One is that open() is a fairly high overhead system call and it so it

won't cope well with traversing a large volume of mounts. Other times

I have introduced open/process/close for individual actions, rather

than keep the object open until it's no longer used, has proven to

impact performance in an unacceptable way.


Second is that, because the mount table lives in a file (actually more

than one with slightly different formats) it needs to be traversed every

time one is looking for a mount which has been shown to be high overhead,

especially if there are many change notifications from the kernel.


Ian