From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Xen 4.2 Release Plan / TODO Date: Thu, 12 Apr 2012 12:00:48 +0100 Message-ID: <1334228448.16387.77.camel@zakaz.uk.xensource.com> References: <1334053490.12209.176.camel@dagon.hellion.org.uk> <1334226256.22289.0.camel@Abyss> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1334226256.22289.0.camel@Abyss> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dario Faggioli Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On Thu, 2012-04-12 at 11:24 +0100, Dario Faggioli wrote: > On Tue, 2012-04-10 at 10:24 +0000, Ian Campbell wrote: > > 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 > allocate it after a while is prone to races (the classical TOCTTOU > 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? I think this is OK, it will effectively be a new API in 4.3 so it should be reasonably easy to do in a compatible manner. Ian.