This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Steven Smith <sos22-xen@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] Mini-OS to use evtchn_port_t for ports and other improvements
From: ramsdell@xxxxxxxxx (John D. Ramsdell)
Date: 27 Jul 2006 08:56:13 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, ramsdell@xxxxxxxxx, Steven Smith <sos22@xxxxxxxxx>, Grzegorz Milos <gm281@xxxxxxxxx>
Delivery-date: Thu, 27 Jul 2006 05:59:02 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060727094920.GA4241@xxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <ogt3bcszejg.fsf@xxxxxxxxxxxxxxx> <20060725102715.GA4351@xxxxxxxxx> <ogtejw99q8n.fsf@xxxxxxxxxxxxxxx> <20060727094920.GA4241@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
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


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