Date: Fri, 7 Apr 2000 00:38:19 -0500 From: Jonathan Lemon <jlemon@flugsvamp.com> To: Matthew Dillon <dillon@apollo.backplane.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: <20000407003819.O80578@prism.flugsvamp.com> In-Reply-To: <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> <200004070510.WAA93968@apollo.backplane.com>
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. -- Jonathan 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?20000407003819.O80578>