> On 9. Apr 2017, at 19:16, Taylor R Campbell
> wrote:
>
>> Date: Sun, 9 Apr 2017 18:47:25 +0200
>> From: "J. Hannken-Illjes"
>>
>>> On 6. Apr 2017, at 11:44, J. Hannken-Illjes wrote:
>>> Good hint.
> Date: Sun, 9 Apr 2017 18:47:25 +0200
> From: "J. Hannken-Illjes"
>
> > On 6. Apr 2017, at 11:44, J. Hannken-Illjes wrote:
> > Good hint. Prepared a partial implementation of
> >
> > int
> > mountlist_iterate(int (*cb)(struct mount *, void
> On 6. Apr 2017, at 11:44, J. Hannken-Illjes wrote:
>
>>
>> On 5. Apr 2017, at 05:14, Chuck Silvers wrote:
>>
>> have you considered a callback-based interface where the loop
>> is inside the iteration API rather than in the caller?
>> the
> On 5. Apr 2017, at 05:14, Chuck Silvers 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
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
Time to start a second round. This time the iterator only, vfs_busy()
and friends deferred to a new thread once the iterator is done.
Changes from the previous proposal:
- Removed the "flags" argument from mountlist_iterator_next(), will
add mountlist_iterator_trynext() and vfs_trybusy() when
> On 2. Apr 2017, at 16:34, Taylor R Campbell
> wrote:
>
>> Date: Sun, 2 Apr 2017 11:09:49 +0200
>> From: "J. Hannken-Illjes"
>>
>>> On 1. Apr 2017, at 23:03, Taylor R Campbell
>>> wrote:
> Date: Sun, 2 Apr 2017 11:09:49 +0200
> From: "J. Hannken-Illjes"
>
> > On 1. Apr 2017, at 23:03, Taylor R Campbell
> > wrote:
> >
> > Any particular reason to use a pointer-to-opaque-pointer here instead
> > of a
> On 1. Apr 2017, at 23:03, Taylor R Campbell
> wrote:
>
>> Date: Thu, 30 Mar 2017 11:21:41 +0200
>> From: "J. Hannken-Illjes"
>>
>> Plan is to untangle the mountlist processing from vfs_busy() / vfs_unbusy()
>> and add an
> Date: Thu, 30 Mar 2017 11:21:41 +0200
> From: "J. Hannken-Illjes"
>
> Plan is to untangle the mountlist processing from vfs_busy() / vfs_unbusy()
> and add an iterator for the mountlist:
Generally seems like a good idea to me!
> - void
In article <534552fb-af29-4219-8390-7514a2665...@eis.cs.tu-bs.de>,
J. Hannken-Illjes 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
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
12 matches
Mail list logo