|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] Re: [PATCH] Mini-OS to use evtchn_port_t for ports and other
Steven Smith <sos22@xxxxxxxxx> writes:
> This mostly looks like a pretty reasonable bit of cleanup, with just
> a few minor niggles.
Steven,
Thank you for your considered opinions. For most of your comments, I
plan to implement your suggestions precisely. I'd like to discuss
just two of them.
> Why maybe_bind? Do you ever expect to need to allocate an unbound
> event channel before you know what handler to use for it?
I wanted to capture the usual pattern of immediately binding a port
after it's allocated, without forcing programmers to follow that
pattern. In the case of evtchn_bind_interdomain, you wondered why I
added the call to clear_event. Should it be decided it should be
eliminated, the use of maybe_bind allows a programmer to still use the
function, but delay the binding until after the programmer calls
clear_event.
> > + evtchn_port_t port = op.u.bind_interdomain.local_port;
> > + clear_evtchn(port); /* Without, handler gets invoked now! */
> Invoking the handler as soon as you bind the interdomain channel is
> a mostly-deliberate part of the interface. If the other end makes
> notifications before you get around to binding they can get lost,
> and forcing the channel to fire as soon as you bind to it avoids
> some potential lost wakeups.
If the handler is invoke whenever the port is bound, there is no
information to be gained as a result of the first invocation of the
handler--as the programmer already knows when it will happen. If it
is important to invoke the handler upon binding, why can't the
programmer simply follow the call the to evtchn_bind_interdomain with
a call to the evt_handler of type evt_handler_t with:
(*evt_handler)(port, NULL, data);
where both port and data are already known for the call to the
function evtchn_bind_interdomain? It's easy to simulate the case of a
handler call on binding with clear_evtchn included, but a pain to
handle the case in which one wants the handler to be invoked only when
a notification arrives, when it is omitted.
John
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|