Date: Thu, 6 Apr 2000 22:10:32 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Jonathan Lemon <jlemon@flugsvamp.com> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, Archie Cobbs <archie@whistle.com>, freebsd-arch@freebsd.org Subject: Re: RFC: kqueue API and rough code Message-ID: <200004070510.WAA93968@apollo.backplane.com> References: <200004070107.SAA97591@bubba.whistle.com> <200004070220.TAA92896@apollo.backplane.com> <20000406220454.J80578@prism.flugsvamp.com> <200004070401.VAA93492@apollo.backplane.com> <20000406234905.K80578@prism.flugsvamp.com>
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.
:--
:Jonathan
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.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004070510.WAA93968>