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

[ramsdell@xxxxxxxxx (John D. Ramsdell)]

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