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 can see each of them has use
cases
For example, (a) could be implemented by using select's xfds (POLLPRI)
to poll for value changes (rfds would still poll for non-zeroness).
Then Michael does not need even to read the eventfd; instead he'd check
POLLIN with a zero timeout.
(b) could be implemented with a flag like Michael did.
Paolo
--
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
