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

[Florian Weimer <fweimer@redhat.com>]

* Miklos Szeredi:

> On Fri, Nov 17, 2023 at 04:50:25PM +0100, Miklos Szeredi wrote:
>> I wonder... Is there a reason this shouldn't be done statelessly by
>> adding an "continue after this ID" argument to listmount(2)?  The
>> caller will just need to pass the last mount ID received in the array
>> to the next listmount(2) call and iterate until a short count is
>> returned.
>
> No comments so far... maybe more explanation is needed.
>
> New signature of listmount() would be:
>
> ssize_t listmount(uint64_t mnt_id, uint64_t last_mnt_id,
> 		  uint64_t *buf, size_t bufsize, unsigned int flags);
>
> And the usage would be:
>
> 	for (last = 0; nres == bufsize; last = buf[bufsize-1]) {
> 		nres = listmount(parent, last, buf, bufsize, flags);
> 		for (i = 0; i < nres; i++) {
> 			/* process buf[i] */
> 		}
> 	}

Is the ID something specific to the VFS layer itself, or does it come
from file systems?

POSIX has a seekdir/telldir interface like that, I don't think file
system authors like it.  Some have added dedicated data structures for
it to implement somewhat predictable behavior in the face of concurrent
directory modification.  Would this interface suffer from similar
issues?

Thanks,
Florian