Avi Kivity wrote: > Gregory Haskins wrote: >> Avi Kivity wrote: >> >>> Avi Kivity wrote: >>> >>>>> So what is your proposal for such interface? >>>>> >>>>> >>>> ->write(). >>>> >>>> >>> Alternatively, a new fileop ->signal_event(), which would map to >>> eventfd_signal() or irqfd_signal(). This would be defined to work in >>> irq contexts. It may also be useful for uio interrupts. >>> >>> >> Hmm...I'm not crazy about either of those. write() has obvious >> 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. >> >> > But again, you're forcing everyone who uses irqfd to require eventfd. > > Maybe we should change eventfd_signal() to fall back to ->write if the > file happens not to be an eventfd. It could also handle the > nonpreemptible context as well. > > Yep, that works. And the nice thing from my perspective is: we don't need a v4 ;) -Greg
Attachment:
signature.asc
Description: OpenPGP digital signature
