[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. 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |