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.
Thoughts?
-Greg
(*) The biggest benefit is that you can do tricks like
"if (preemptible()) do_it_now(); else
do_it_later();"
Attachment:
signature.asc
Description: OpenPGP digital signature
