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
	  that process).
	- 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  <lukem@wasabisystems.com>  http://www.wasabisystems.com
>  > Luke Mewburn     <lukem@netbsd.org>      http://www.netbsd.org
>  > Wasabi Systems - providing NetBSD sales, support and service.
> 
> -- 
>         -- Jason R. Thorpe <thorpej@zembu.com>

-- 
Luke Mewburn  <lukem@wasabisystems.com>  http://www.wasabisystems.com
Luke Mewburn     <lukem@netbsd.org>      http://www.netbsd.org
Wasabi Systems - providing NetBSD sales, support and service.