Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 7 Apr 2000 00:38:19 -0500
From:      Jonathan Lemon <>
To:        Matthew Dillon <>
Cc:        Jonathan Lemon <>, Archie Cobbs <>,
Subject:   Re: RFC: kqueue API and rough code
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <> <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Thu, Apr 06, 2000 at 10:10:32PM -0700, Matthew Dillon wrote:
>     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.

I haven't missed the point, note the 'struct user_data *udata' within
the `kevent' structure.

>     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.

No, I'm not copying data _to_ the user structure at all.  I'm just
keeping the user-level pointer around so it can be used by userspace
rather than forcing it to maintain an (ident/filter) mapping.

>     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 

Yes, but that's not how this necessarily works, it isn't AIO.  I can
create a huge buffer to copy in 10,000 events at once, and then read
events out into another buffer in chunks of 100 if I want.  I don't
necessarily have to, in fact I definitely *don't* want to keep the
original structures around where I copied data from.

> :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.

But that's essentially what I did, but I haven't defined a "base user
structure" for the kernel, since it may not be needed.  Recall that 
each filter has its own small code segment associated with it.  So 
the "base structure" can be different for those sections of code which
require it, and nonexistent for those that don't.  Those filters which
need a large amount of extended data can use the `udata' pointer for 
access to an extended structure, and those filters which don't know 
anything about this will still play nice.

>     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
>     complex.

I disagree that it's complex, I think that it's amazingly simple.
The difficulty is that each user program has a different idea of 
what state it wants to keep, what structure it needs to keep around,
and what metadata is required.  Rather than trying to come up with
some case that will cover all requirements, I just want to come up
with the bare minimum, and allow a method of extension.

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

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