Avi Kivity wrote:But again, you're forcing everyone who uses irqfd to require eventfd.
Avi Kivity wrote:Hmm...I'm not crazy about either of those. write() has obvious
Alternatively, a new fileop ->signal_event(), which would map toSo what is your proposal for such interface?->write().
eventfd_signal() or irqfd_signal(). This would be defined to work in
irq contexts. It may also be useful for uio interrupts.
limitations both from a interrupt execution context, as well as the
awkwardness of dealing with creating+passing a viable "userspace"
pointer from kernel code. On the other hand, a new fileop doesn't quite
seem appropriate either since it doesn't apply to the overall fileop
abstraction very well.
We could potentially have a separate vtable interface just for
event-type fds, and make eventfd and irqfd the first implementations. But I am not sure it is worth it. What I suggest is that we work within
the existing eventfd interface. It was designed specifically to signal
events, after all.
If at some point in the future we need to ensure that the callbacks are
not invoked from a preempt-off/irq-off critical section, we can revist
the eventfd internals at that time. Note that since we would like to
support signaling from interrupt context anyway, trying to get rid of
the wqh critical section that we have today may be a fools errand (*). Instead, we should probably focus on making the injection path support
non-preemptible contexts, as this will have the biggest benefits and
gains in the long run.