DragonFly kernel List (threaded) for 2011-02
Re: race condition in knote deletion?
On Wed, Feb 2, 2011 at 10:59 AM, Matthew Dillon
> :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.
> 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.
> Matthew Dillon
This could conceivably be done using the existing kq initialization
functions that are embedded in the various dev_ops and other
structures. Instead of just assigning to (knote *)->kn_fop the static
filterops, this could be rolled up into public function(s) that these
initialization functions would call. This seems like a logical and
relatively straightforward improvement that might even be able to
simplify some of the boilerplate used in the many kqfilter init
That said, I don't see how either of these approaches is mutually
exclusive. It might be beneficial to do both.