DragonFly kernel List (threaded) for 2011-02
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: race condition in knote deletion?
:I have been contemplating this a bit too -- how to make the filters
:more stateless (get rid of the lists) or at least make the list
:handling more implicit.
:
:This seems like a reasonable approach. I think I would be in favor of
:going about a refactor in the way you describe, assuming that we
:export a new interface/api from devfs for devices with a devfs node
:and that api is kept seperate from the existing kq api's (I guess it
:would be a wrapper), which will continue to service files/sockets (and
:devfs) directly. I think it is already a relatively confusing
:subsystem and drawing a line there would at least keep it from
:becoming more complicated.
:
:Sam
Another option is to register the kq lists via a kernel API, and
have the kernel kqueue code kmalloc() the structures independently.
Then on detach the kqueue API can clear the callback into the device
and keep the structure intact until all users of it go away.
We already have a structure that will almost do it.... struct filterops.
The problem with struct filterops is that devices will use just one copy
of the struct filterops for all the sub-devices so it isn't a suitable
structure to hold the kq lists itself. Plus it is declared statically
so if a module detaches the declaration goes away (which is bad).
This kinda implies we should refactor the entire initialization portion
of the API, perhaps just using struct filterops as a skeleton and
have the kqueue code allocate its own internal copy for each instance
that also includes the kq lists.
-Matt
Matthew Dillon
<dillon@backplane.com>
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]