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] Re: libxenlight or libxenheavy?

To: Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: libxenlight or libxenheavy?
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Tue, 1 Dec 2009 11:23:24 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Tue, 01 Dec 2009 03:20: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
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Mon, 30 Nov 2009, 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:

First of all I am really glad that you brought this up, because it is
very important that we get this clear: libxenlight must remain
lightweight and small at all costs.
Obviously everyone has a different feeling about what's small and what's
not but that is the general idea.

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

On this point I disagree with you: I am glad that blktap2 is simpler
but it shouldn't be threated differently from blktap1 on this basis.
Besides I wanted to be able to use blktap2 in place of blktap1
transparently whenever possible.
Finally, if your high level toolstack really wants, can still manage
tapdisk2 devices directly.

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

You have a very good point here and I think we should fix this soon.

That said, let me just explain why we need these watches: we want to
abstract xenstore from the high level toolstack, so that it doesn't have
to access xenstore unless it really wants to.

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] Re: libxenlight or libxenheavy?, Stefano Stabellini <=