Steven Smith <sos22-xen@xxxxxxxxxxxxx> writes:
> > > Why maybe_bind? ...
> That's not a bad idea, but I'd rather leave this until we have an
> example of some actual code which needs it.
Maybe bind has been eliminated.
>
> > > > + 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.
> > 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.
> I think you have a point here. Consider my objection withdrawn.
I added the clear_evtchn back in. Here is the patch freshly minted
patch.
John
The enclosed patch modifies Mini-OS so it uses evtchn_port_t for
ports, instead of the current mixture of u32's and int's. It provides
a name for the type of an event channel handler in events.h. It
modifies evtchn_alloc_unbound so that it can be used to set up an
event channel to a domain other than zero. It adds
evtchn_bind_interdomain to support the other half of event channel set
up. Finally, it adds a routine that translates grant table operation
status values to their string equivalent.

Attachment: evtchn.patch
Description: event channel patch

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel