Re: [Xen-devel] libxenlight or libxenheavy?

[Jean Guyader <jean.guyader@xxxxxxxxx>]

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.

Jean

> - 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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel