libxenlight or libxenheavy?

[Andres Lagar-Cavilla <andres@lagarcavilla.com>]

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.

Andres