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 ...
indeed.
>
> - 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.
--
Vincent
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home