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: Vincent Hanquez <vincent.hanquez@xxxxxxxxxxxxx>
Date: Tue, 1 Dec 2009 06:12:54 +0000
Accept-language: en-GB, en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Mon, 30 Nov 2009 22:03:35 -0800
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
Thread-topic: [Xen-devel] libxenlight or libxenheavy?
User-agent: Mutt/1.5.20 (2009-06-14)
On Mon, Nov 30, 2009 at 07:08:47PM +0000, Andres Lagar-Cavilla wrote:
> 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:

I agree with your observation. the goal for libxenlight is not to provide
a full hand on solutions, but a bunch of helper functions to do one thing
and only one thing "plug a disk", "suspend a domain".
I think however that whilst it's not going only in the right direction,
the early stage of the library means that we need for testing a lot
of things that shouldn't be in the API.

once we reach a stage where everything works, i'm sure that integrating
into proper management stack will means that the API will simplify as
things become obsolete or useless.

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

This whole part is the mess, i wouldn't rely on the lib for now for thoses.
the opensource xs library need some cleanup in the watch processing department
in the first place.


Xen-devel mailing list

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