From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Smith Subject: Re: [PATCH] Mini-OS to use evtchn_port_t for ports and other improvements Date: Thu, 27 Jul 2006 10:49:20 +0100 Message-ID: <20060727094920.GA4241@cam.ac.uk> References: <20060725102715.GA4351@cam.ac.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1039579999==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Mime-version: 1.0 Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "John D. Ramsdell" Cc: xen-devel@lists.xensource.com, Steven Smith , Grzegorz Milos List-Id: xen-devel@lists.xenproject.org --===============1039579999== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj" Content-Disposition: inline --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > > 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. --9amGYk9869ThD9tj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEyIwgO4S8/gLNrjcRAsYGAKCWhK+ET5dwFObCgxZmhmJ5NzxdJgCeNsly 2oSQxX4GlvOtTm+LXenEWbs= =4Rnz -----END PGP SIGNATURE----- --9amGYk9869ThD9tj-- --===============1039579999== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1039579999==--