Subject: Re: kqueue() update; ready to commit?
To: Jason R Thorpe <firstname.lastname@example.org>
From: Luke Mewburn <email@example.com>
Date: 05/24/2001 15:49:40
On Mon, May 21, 2001 at 08:26:43AM -0700, Jason R Thorpe wrote:
> On Mon, May 21, 2001 at 05:04:22PM +1000, Luke Mewburn wrote:
> > The work is almost done, and I need some feedback from people with
> > more kernel experience than I, because I'd like to get this work
> > committed into our tree real soon now. There's a few places in the
> > code where I wasn't sure about how to port certain FreeBSD locking
> > features (for example), and I've marked those with `XXXLUKEM'.
> Have you addressed the concerns of:
> - Acquiring the number of named filters.
Nothing implemented yet. I'm trying to decide if we add another system
call for this, or use sysctl(). Actually, I sysctl will not work right
now because it's not dynamic nor does it support string based lookups.
So, do we add a third system call which userland calls to map a name
to a kevent id?
> - Need 3 filter entry points for them to be truly useful.
> that have been raised each time kqueue has been discussed?
> Sadly, the easy one to implement (name-to-number) is the one that doens't
> directly affect the kevent API itself -- the more complicated one, the
> 3-filter-entry-points, does. And since it does change things a bit, we
> need to have that implemented before its brought into our tree.
From what I read in the archives and you've said in the past, there
doesn't appear to be exact consistency about what entry points are
required. Bill Sommerfeld suggested three callbacks:
- one invoked when a process first asks for the event (invoked in
- one invoked when the event happens (which could be in any context
-- interrupt level, process context of some other process, ...)
- one invoked when the event actually gets posted to the process
(again invoked in that process)
The internal API already supports three entry points:
attach called when event request registered (with EV_ADD)
detach called when event request delete (EV_DELETE)
event the actual filter
Could the attach & detach routines be used to perform the functionality
that Bill & you would like (memory management, etc), or do we need
more callbacks in light of this?
> > As to the code itself; I've been running this for a while on a
> > couple of my systems. There doesn't seem to be any negative impact
> > on running this code, either when not explicitly using the kqueue
> > mechanism, or in code that uses kqueues for various features.
> > I've uploaded the latested diff, test files, and todo list to:
> > ftp://ftp.netbsd.org/pub/NetBSD/misc/lukem/
> > The relevant files are:
> > ftp://ftp.netbsd.org/pub/NetBSD/misc/lukem/kqueue-010521.diffs
> > ftp://ftp.netbsd.org/pub/NetBSD/misc/lukem/kqueue-todo
> > ftp://ftp.netbsd.org/pub/NetBSD/misc/lukem/kqueue-test.tar.gz
> > As mentioned above, I'd like to commit this fairly soon, so good
> > technical feedback would be appreciated!
> > Thanks,
> > Luke.
> > --
> > Luke Mewburn <firstname.lastname@example.org> http://www.wasabisystems.com
> > Luke Mewburn <email@example.com> http://www.netbsd.org
> > Wasabi Systems - providing NetBSD sales, support and service.
> -- Jason R. Thorpe <firstname.lastname@example.org>
Luke Mewburn <email@example.com> http://www.wasabisystems.com
Luke Mewburn <firstname.lastname@example.org> http://www.netbsd.org
Wasabi Systems - providing NetBSD sales, support and service.