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


Re: [Xen-devel] libxenlight or libxenheavy?

To: Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] libxenlight or libxenheavy?
From: Jean Guyader <jean.guyader@xxxxxxxxx>
Date: Tue, 1 Dec 2009 11:24:46 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Delivery-date: Tue, 01 Dec 2009 03:25:09 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=EE8urljqtt57GNW/gCjC9EW788H2GIBw9wjNOGhoRBM=; b=dyw+ehku3XKOp2pt84hsHHVavjB8FNetjLrC0diRpH9q60jZmawZmAEmphS6uoPLNl c6GxJJs5UH2fXw8H46+KBnFt7RM3s/tUizTw6P1iqJC0wwha8jmW720eP3hK6XF8F+Kr TS7Anl/p8SMTKvDduzpwmXRiWnkHp2g29M9Gs=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qXccDt52Q2/PdMwqh9yEZnguWragqZ5TpW/Kj40fz8ewfbgYx3Y1QtMvD4a6PZceBv UJ+BN0JHXtUAs4fa2DHI763l83K0NbmfTImdOQPikyquTj98cok0tEsMIHw3/+TxVRXS 22hcv11h9PNCJGb2w6xq+z+G/DTONNpJKVP80=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B14183F.3070801@xxxxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4B14183F.3070801@xxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
2009/11/30 Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>:
> Aside of the tongue in cheek title, I'd like to get a feel for where is
> libxenlight going. I love having a library that gives me three
> straight-forward C calls to create a domain, and I think it's an excellent
> vehicle to writing control stacks.
> But some of the latest patches have grown/bloated the library in directions
> I don't think are useful. This an obviously subjective take on the matter,
> but here are two examples:
> - Managing tapdisk2 devices in libxenlight: why at all? An upper-level
> control stack can (will have to) vet the configuration stanza of the
> tapdisk2 process, and it can then launch it and manage its life-cycle (i.e.
> echo appropriate commands to the sysfs interface). One of the great
> advantages of tapdisk2 is that it looks like a regular block device:
> /dev/xen/blktap-2/tapdev0. Libxenlight doesn't need to know this is any
> different from a regular block device ...

I don't think that really a bad thing. The top level toolstack can
still just give block
device to libxl and libxl will have no idea whether or not it's a
blktap2 device and
obviously at this point will be responsible of the creation and
destruction of those one.

I believe it's important to have a basic VHD support into the low
level library so you don't
need to have anything on the top to be able to use VHD.


> - Asynchronous notifications via xenstore watches: I've seen at least two
> locations (device deletion during destroy and waiting for domain death)
> where a watch on a xenstore path is placed by the library, and later
> xs_read_watch is called. According to my limited understanding, this could
> read *any* firing watch placed by the same process, and the code will
> discard it unless it's the one we are looking for. Thus destroying
> information useful to someone else. I cannot have two concurrent (or even
> interleaved) calls to libxenlight on these code paths, because they could
> read each other's watches. Why not leave these to an upper-level stack,
> which in all likelihood will have to deal with lots of asynchronous events?
> As it stands, I have to write my code *around* libxenlight, which kind of
> defeats the purpose.
> Anyway, these are two observations. Libxenlight is great. And to buy back
> some of the love I spent ranting, I'll follow this with 14 patches. These
> are all based off20522: abc6183f486e
> <http://xenbits.xen.org/xen-unstable.hg?rev/abc6183f486e>. Some are more
> RFC-ish in nature, but there a fair bit of fixes. They apply -p1 (sorry).
> Just let me know if you need a rebasing or whatever.

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>