On Thu, 27 Aug 2009, Michael S. Tsirkin wrote: > Oh, I stopped pushing EFD_STATE since we have a solution. > I am just trying to grok what does and what does not consititute a > use-once addition, in your mind, and what does and what does not > belong in eventfd. The reason atomic does not belong there and > semaphore does is because one waits on semaphore but not > on atomic? Is that it? An atomic variable is not a synchronization interface. Even if it'd come up that we really need an atomic variable abstraction via an fd, this should not go via eventfd. Yeah, maybe the name syncfd would have been better, but the very reason why eventfd born was to allow KAIO to signal events to poll/select/epoll. That first implementation was also usable as a mutex. Then it was propsed to make eventfd to act as a semaphore too. Code was trivial, a semaphore fitted the interface, and the abstraction was a pretty damn known too. So it went in. Yes, you could have implemented a semaphore with the existing eventfd, by reading the counter and writing counter-1. But again, a semaphore was something widely known and generic enough, and was fitting the bill. - 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
