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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* 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





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux