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


[Xen-devel] libxenlight or libxenheavy?

To: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] libxenlight or libxenheavy?
From: Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>
Date: Mon, 30 Nov 2009 14:08:47 -0500
Delivery-date: Mon, 30 Nov 2009 11:09:16 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20090817)
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 ...

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