On Tue, 16 Jun 2009, Gregory Haskins wrote: > Davide Libenzi wrote: > > On Tue, 16 Jun 2009, Gregory Haskins wrote: > > > > > >> Does this all make sense? > >> > > > > This conversation has been *really* long, and I haven't had time to look > > at the patch yet. But looking at the amount of changes, and the amount of > > even more changes talked in this thread, there's a very slim chance that > > I'll ACK the eventfd code. > > You may want to consider a solution that does not litter eventfd code that > > much. > > > > > > - Davide > > > > > > > Hi Davide, > > I understand your position and value your time/insight into looking at > this things. > > Despite the current ongoing discussion, I still stand that the current > patch is my proposed solution (though I have yet to convince Michael). > But in any case, if you have the time, please look it over because I > still think its the right direction to head in. I don't think so. You basically upload a bunch of stuff it could have been inside your irqfd into eventfd. Now the eventfd_signal() can magically sleep, or not, depending on what the signal functions do. This makes up a pretty aweful interface if you ask me. A lot simpler and cleaner if eventfd_signal(), like all the wake up functions inside the kernel, can be called from atomic context. Always, not sometimes. - Davide -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
