On Wed, Feb 2, 2011 at 10:59 AM, Matthew Dillon
<dillon@apollo.backplane.com> wrote:
>
> :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
>
> ꀠ孭nother option is to register the kq lists via a kernel API, and
> ꀠ温ave the kernel kqueue code kmalloc() the structures independently.
> ꀠ糍hen on detach the kqueue API can clear the callback into the device
> ꀠ乸nd keep the structure intact until all users of it go away.
>
> ꀠ咗e already have a structure that will almost do it.... struct filterops.
> ꀠ糍he problem with struct filterops is that devices will use just one copy
> ꀠ漑f the struct filterops for all the sub-devices so it isn't a suitable
> ꀠ澵tructure to hold the kq lists itself. 嘭lus it is declared statically
> ꀠ澵o if a module detaches the declaration goes away (which is bad).
>
> ꀠ糍his kinda implies we should refactor the entire initialization portion
> ꀠ漑f the API, perhaps just using struct filterops as a skeleton and
> ꀠ温ave the kqueue code allocate its own internal copy for each instance
> ꀠ濳hat also includes the kq lists.
>
> ꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀭMatt
> ꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠ嗰atthew Dillon
> ꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀼdillon@backplane.com>
>
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
functions.
That said, I don't see how either of these approaches is mutually
exclusive. It might be beneficial to do both.
Sam