In article <534552fb-af29-4219-8390-7514a2665...@eis.cs.tu-bs.de>,
J. Hannken-Illjes <hann...@eis.cs.tu-bs.de> wrote:
>Currently vfs_busy() / vfs_unbusy() get used to
>
>- Enter/leave a critical section against unmounting
>
>- Add a reference to the mount
>
>- return the next mount from the mountlist on error
>
>Plan is to untangle the mountlist processing from vfs_busy() / vfs_unbusy()
>and add an iterator for the mountlist:
>
>- void mountlist_iterator_init(mount_iterator_t **)
>  to initialize an iterator in mounted order.
>
>- void mountlist_iterator_init_reverse(mount_iterator_t **)
>  to initialize an iterator in reverse mounted order.
>
>- void mountlist_iterator_destroy(mount_iterator_t *)
>  to destroy an iterator aquired with one of the above.
>
>- struct mount *mountlist_iterator_next(mount_iterator_t *, int)
>  to retrieve the next mount from an iterator or NULL if done.
>  The mount is returned vfs_busy'd, caller has to vfs_unbusy.
>  Accepts a flag MNT_NOWAIT to skip mounts whose unmount is in progress.
>
>- struct mount *_mountlist_next(struct mount *)
>  a lockless variant to be used from DDB only.
>
>Diffs are here: https://www.netbsd.org/~hannken/ml_iterator/
>
>Comments or objections anyone?

LGTM, but can't all the copies of the dostatvfs iteration be merged
together and utilize a converter function to handle the data massaging?

christos

Reply via email to