[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Re: [PATCH] Mini-OS to use evtchn_port_t for ports and other improvements

Steven Smith <sos22@xxxxxxxxx> writes:

> This mostly looks like a pretty reasonable bit of cleanup, with just
> a few minor niggles.


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

> > +    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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.