Avi Kivity wrote: > Gregory Haskins wrote: > > > >>> But eventfd_signal basically marries us to eventfd. >>> >> >> Well, only if we expect the fd to have eventfd semantics. There are >> advantages to doing so, as we have discussed, because things like AIO >> can polymorhpically signal an interrupt without even knowing whats >> behind the eventfd. But this isn't a strict requirement to support >> AIO. Really all we need is a way for both kernel and userspace to >> signal. Perhaps I should export an "irqfd_signal()" function from kvm, >> which today will map to eventfd_signal(), and tomorrow to ??. I don't >> think using f_ops->write() is an option for in-kernel signaling, so we >> need some kind of interface here. >> >> Does that sound reasonable? >> > > irqfd_signal() ties the user of irqfd to kvm. I want this user to be > independent of kvm; it should work with eventfd, kvm's eventfd > lookalike (if we move away from eventfd) or pipes. So what is your proposal for such interface? -Greg
Attachment:
signature.asc
Description: OpenPGP digital signature
