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