[Xen-devel] Re: libxenlight or libxenheavy?

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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