WARNING - OLD ARCHIVES

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/
Xen

xen-devel

[Top] [All Lists]

[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: 2006年7月27日 10:49:20 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Steven Smith <sos22@xxxxxxxxx>, Grzegorz Milos <gm281@xxxxxxxxx>
Delivery-date: 2006年7月27日 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.
Steven.

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>
Previous by Date: Re: [Xen-devel] [PATCH][ACM] kernel enforcement of vbd policies via blkback driver , Harry Butterworth
Next by Date: Re: [Xen-devel] [PATCH] Add lost logic for VGA initialization , Christian Limpach
Previous by Thread: [Xen-devel] Re: [PATCH] Mini-OS to use evtchn_port_t for ports and other improvements , John D. Ramsdell
Next by Thread: [Xen-devel] Re: [PATCH] Mini-OS to use evtchn_port_t for ports and other improvements , John D. Ramsdell
Indexes: [Date] [Thread] [Top] [All Lists]

Copyright ©, Citrix Systems Inc. All rights reserved. Legal and Privacy
Citrix This site is hosted by Citrix

AltStyle によって変換されたページ (->オリジナル) /