On Thu, 20 Aug 2009, Paolo Bonzini wrote: > On 08/20/2009 07:44 PM, Davide Libenzi wrote: > > On Thu, 20 Aug 2009, Avi Kivity wrote: > > > > > On 08/20/2009 07:20 PM, Davide Libenzi wrote: > > > > > > > > I briefly looked at this while in vacation, although I did not reply > > > > hoping the horrible feeling about this code would go away. > > > > It didn't. > > > > I find this to be an ugly and ad-hoc multiplexing of eventfd with added > > > > functionalities of questionable general use. > > > > I'm pretty sure you can do better on KVM side, to solve the problem > > > > w/out > > > > littering eventfd. > > > > > > While we could argue about this my feeling is that we should drop this, at > > > least until we can quantify what benefit it has and whether there are any > > > Davide-acceptable alternatives. > > > > I really didn't mean to be harsh, but seriously, we cannot just have a > > Multiplexing Feast over eventfd, with one-time users. > > EFD_STATE actually does two changes: a) makes read block until the value > changes; b) makes each write override the previous one. How would you feel if > the two changes were separated? I'm afraid that splitting the change won't make less inappropriate for eventfd. I've no doubt KVM needs something like this, but this just don't belong to eventfd, which act as either a mutex or a semaphore. This EFD_STATE does not belong to a generic interface, proof of which is the lack of such abstraction in any generic library I'm aware of. This aside from any consideration about how the code will look with that multiplexing in place. - 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
