On Wed, Feb 2, 2011 at 10:59 AM, Matthew Dillon <[email protected]> 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 > > 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 > <[email protected]> >
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
