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: "John D. Ramsdell" <ramsdell@xxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] Mini-OS to use evtchn_port_t for ports and other improvements
From: Steven Smith <sos22-xen@xxxxxxxxxxxxx>
Date: Thu, 27 Jul 2006 10:49:20 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Steven Smith <sos22@xxxxxxxxx>, Grzegorz Milos <gm281@xxxxxxxxx>
Delivery-date: Thu, 27 Jul 2006 02:50:13 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <ogtejw99q8n.fsf@xxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > 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.
That's not a bad idea, but I'd rather leave this until we have an
example of some actual code which needs it.

> > > +    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.


Attachment: signature.asc
Description: Digital signature

Xen-devel mailing list