From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: Xen 4.2 Release Plan / TODO Date: Thu, 12 Apr 2012 12:24:16 +0200 Message-ID: <1334226256.22289.0.camel@Abyss> References: <1334053490.12209.176.camel@dagon.hellion.org.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2384065376346378331==" Return-path: In-Reply-To: <1334053490.12209.176.camel@dagon.hellion.org.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: xen-devel List-Id: xen-devel@lists.xenproject.org --===============2384065376346378331== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-n5LjIGad91JqeUfaXutf" --=-n5LjIGad91JqeUfaXutf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2012-04-10 at 10:24 +0000, Ian Campbell wrote:=20 > Lots more DONE this week, still a few big ticket items or items with no > progress (that I've noticed) please let me know if the status of > anything has changed. > Here I am. :-) > tools, blockers: > * libxl stable API -- we would like 4.2 to define a stable API > which downstream's can start to rely on not changing. Aspects of > this are: > * Safe fork vs. fd handling hooks. Involves API changes > (Ian J, patches posted) > * locking/serialization, e.g., for domain creation. As of > now, nothing is provided for this purpose, and > downstream toolstacks have to put their own mechanisms > in place. E.g., xl uses a fcntl() lock around the whole > process of domain creation. It should OTOH be libxl job > to offer a proper set of hooks --placed at the proper > spots during the domain creation process-- for the > downstreams to fill with the proper callbacks. (Dario > Faggioli) > * Thinking to defer this until 4.3? > Here's the point. This was raised for the following main reasons: 1. xl holds a lock during domain creation for way too long 2. checking for free memory in xl when it is Xen that will actually=20 allocate it after a while is prone to races (the classical TOCTTOU=20 condition) We thought both these things to be addressable by messing around with locks, but a more careful analysis revealed we can't solve 2. in a sane enough way by just doing that (i.e., messing with lock, moving it around, etc.). That being the case, yes, I think we can move this forward toward 4.3 without much problems, and I propose doing so. Thoughts? Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-n5LjIGad91JqeUfaXutf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk+GrVAACgkQk4XaBE3IOsSrbwCfei/qn2hNzgHm0QWSTBWCNwkD X4QAn3BU3o+xxp1WwIgOcaHRg8b5lGBp =jYl3 -----END PGP SIGNATURE----- --=-n5LjIGad91JqeUfaXutf-- --===============2384065376346378331== 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.xen.org http://lists.xen.org/xen-devel --===============2384065376346378331==--