> On 6. Apr 2017, at 11:44, J. Hannken-Illjes <hann...@eis.cs.tu-bs.de> wrote: > >> >> On 5. Apr 2017, at 05:14, Chuck Silvers <c...@chuq.com> wrote: >> >> have you considered a callback-based interface where the loop >> is inside the iteration API rather than in the caller? >> the vfs_busy/unbusy could also be hidden in the iteration API >> so that the callback would not need need to worry about it at all. >> >> I looked at how the iteration stuff is used in your patches >> (the first one, I haven't looked in the latest one in detail) >> and it looks like most of users would be fine with not being able >> to do anything after vfs_unbusy(). the one place that really does >> want to do more after vfs_unbusy() is vfs_unmountall1(), >> but that could be rewritten to loop unmounting the last mount >> in the list until they're all gone. >> >> I think this would further simplify most (if not all) cases of >> mountlist iteration. > > Good hint. Prepared a partial implementation of > > int > mountlist_iterate(int (*cb)(struct mount *, void *), void *arg) > > to take "mp" busy and call "cb(mp, arg)" for all mounted file systems. > > A non waiting variant "mountlist_iterate_nowait()" could be added > when it gets needed. > > Changed "vfs_unmountall1()" to retrieve mounts in descending > generation order which has the additional benefit that we don't > need reverse traversals any more. > > Diffs are here: https://www.netbsd.org/~hannken/ml_iterator2a/ > > I prefer this API, opinions?
If no one objects I will commit this iterator on Tuesday, April 11. -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)