From owner-freebsd-arch Thu Apr 6 22:10:52 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 7695837B5ED for ; Thu, 6 Apr 2000 22:10:41 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id HAA16705 for ; Fri, 7 Apr 2000 07:14:16 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id HAA35276 for freebsd-arch@freebsd.org; Fri, 7 Apr 2000 07:10:40 +0200 (CEST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 3128837B5ED for ; Thu, 6 Apr 2000 22:10:34 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id WAA93968; Thu, 6 Apr 2000 22:10:32 -0700 (PDT) (envelope-from dillon) Date: Thu, 6 Apr 2000 22:10:32 -0700 (PDT) From: Matthew Dillon Message-Id: <200004070510.WAA93968@apollo.backplane.com> To: Jonathan Lemon Cc: Jonathan Lemon , Archie Cobbs , freebsd-arch@freebsd.org Subject: Re: RFC: kqueue API and rough code 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> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message