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 
					<[e-mail]>