Re: race condition in knote deletion?
On Tue, Feb 1, 2011 at 8:58 PM, Matthew Dillon
<dillon@apollo.backplane.com> wrote:
> ꀠ嘢ne thing I think may be a liability is the knote migration to devfs
> ꀠ漑n detach. 啱 think it might be better to implement the knotes in devfs
> ꀠ漑nly and make devices use the devfs-supplied structure(s) (probably just
> ꀠ氽ev_t, even) for managing knotes.
>
> ꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀭMatt
>
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
討論串 (同標題文章)
完整討論串 (本文為第 5 之 7 篇)：