Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 6 Apr 2000 22:10:32 -0700 (PDT)
From:      Matthew Dillon <>
To:        Jonathan Lemon <>
Cc:        Jonathan Lemon <>, Archie Cobbs <>,
Subject:   Re: RFC: kqueue API and rough code
Message-ID:  <>
References:  <> <> <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

:Exactly.  Now, this is just what the code does at the moment, only
:slightly differently.  In the scheme above, every "registration", 
:via kqueuectl, copies in (filter, fd, ev), and then the kernel
:additionally copies in (data, flags), as those are also input parameters.
:So far, this turns out to be one more element than the current structure.
:When returning data, the kernel does a copyout of (data, flags) to
:the saved event structure, and then copies out the pointer to the
:structure.  This saves one copy over what I have now.
:In total, this comes out equal to just copying (data,flags,ident,filter).
:The only difference that I can see is that with the scheme above,
:the user-level code must keep the data in the same location, which
:may not be ideal for some applications.  It also binds the implementation
:between user and kernel a little tighter than I would like.

    No, you're missing the point... where did the 'user data' go in my
    second scheme?  There's no field for it anymore, and that's because
    the user data structure pointer you pass to the kernel is the SAME
    one that is returned.

    In the first scheme you are copying data to an arbitrary user structure,
    the user structure itself cannot represent any user-data because there
    is no relationship between the address of the structure that was passed
    and the address of the structure the copyout occured to.

    The whole point of this is to be able to associate arbitrary data
    with the event.  In your scheme there is no way to do that (and using
    the descriptor is not a good idea for all the reasons I outlined before).

    In this scheme you can associate as much data as you want with the event.

    I don't understand your comment about 'binding the implementation'.  
    No such thing is occuring.  Sure, the user structure has to stay around..
    that's not a big deal, it's how aio works.  It certainly does not 
    restrict your options at all, since you need meta-data to control handling
    of the event anyway.  The meta-data might as well be integrated into
    the structure because if it isn't you have to implement it separately
    anyway, and you gain absolutely no advantage whatsoever doing that.

:Looking at it another way, I use (event/filter) as a capability
:descriptor to user space rather than a pointer.  It seems that if
:you simply had (void *udata) field to the kevent structure,
:then it would be easy for you to implement your method above.  Then
:specific filters (which understand the layout of the structure
:that *uevent points to) could be written access to extended data:

    Yes and no.  The problem is that there is no room for extension to
    (for example), handle a direct threads, signal, or function dispatch
    when you do things that way.

    By creating a base user structure which is not copied to the kernel
    and contains sufficient reserved fields to extend the kernel 
    functionality, you wind up keeping the syscall API compatible with
    future additions.

:	struct user_event {
:		int 	priority;
: 	    	void	(*dispatch)(struct event *ev);
:		int 	thread;
:		struct kevent {
:	 	    int		fd;
: 		    short	filter;
: 		    short	flags;
:	 	    long	data;
:		    void	*uevent;
:		}
:	}
:How about that?  The kernel only cares about `struct kevent'.  
:It won't touch the 'uevent' pointer at all.   In theory, you
:could use the `data' field as a pointer, but for uniformity
:I'd rather just add one more field.

    I'm not sure what you are getting at here... you are trying to maintain
    the copyin/copyout semantics just so the user program doesn't have to
    keep the original event structure around after queueing the event?  That
    doesn't make much sense, the user program has to keep some state around
    anyway, making that state the original event structure makes things
    a whole lot easier then forcing the user program to come up with its
    own scheme to store the state separately.  All you are doing with the
    copyin/copyout scheme is forcing the user program to become unnecessarily

					Matthew Dillon 

To Unsubscribe: send mail to
with "unsubscribe freebsd-arch" in the body of the message

Want to link to this message? Use this URL: <>