From mboxrd@z Thu Jan 1 00:00:00 1970 From: ramsdell@mitre.org (John D. Ramsdell) Subject: Re: [PATCH] Mini-OS to use evtchn_port_t for ports and other improvements Date: 25 Jul 2006 20:14:32 -0400 Message-ID: References: <20060725102715.GA4351@cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: In-Reply-To: <20060725102715.GA4351@cam.ac.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Steven Smith Cc: ramsdell@mitre.org, xen-devel@lists.xensource.com, Grzegorz Milos , sos22@srcf.ucam.org List-Id: xen-devel@lists.xenproject.org Steven Smith 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