>>> On Mon, May 14, 2007 at 1:23 PM, in message <[EMAIL PROTECTED]>, Avi Kivity <[EMAIL PROTECTED]> wrote: > >> Do you close the signaled fd after receiving the signal/event? If you >> don't close it, eventfd will always return ready (POLLIN). >> > > We don't. Anyway, that's what we thought. Thanks for the confirmation. >
And plus I just finished converting to Davide's eventfd, so its moot ;) On that topic, I could use some advice: I was originally planning on adding a new ioctl like KVM_VCPU_CREATE_EVENTFD which would allocate a new eventfd and return it. However, I soon realized that the only method to create an eventfd is sys_eventfd(), which is not exported by the eventfd.h headerfile (presumably this must be a new system call). So based on that, I figured I would change the model so that the usermode app should call the eventfd open() call on its own, and then they could register the fd with me. So KVM_VCPU_CREATE_EVENTFD becomes KVM_VCPU_SET_EVENTFD (where -1 "unregisters" it). Does this sound like a reasonable approach? If so, how does the usermode app actually open the eventfd today? Is there a new glibc that I need to get the new system call? Or can the app use open() somehow? If open(), what is the path that should be specified? Conversely, if my first approach was the right one how do I invoke the sys_eventfd()? Is there a way to invoke system calls in kernel mode? A better way? Any advice appreciated. -Greg ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
