Re: future plans for libxl?

[Vincent Hanquez <vincent.hanquez@eu.citrix.com>]

On 15/04/10 09:22, Andre Przywara wrote:
> OK, what is missing currently is nr_nodes, {hw,virt}_caps and the whole
> bunch of (currently in flux) NUMA information. I think the whole NUMA
> info should be moved into either a topology or a NUMA structure
> (together with libxl_get_... functions). But I'd like to see at least
> nr_nodes and the caps within the physinfo structure. One can debate
> about the nr_nodes fields, though.

Not sure about numa, it seems to be in flux in xen-unstable at the 
moment, so i'ld rather leave this interface alone, until it's sorted.

For the caps things, you might want to consider something a bit more 
high level than passing a bitfields through. For example you could 
actually transform the caps bitfields into an array of decoded values.
that's a bit more friendly to use from a user of libxl PoV.

> What about xc_version(), by the way? This provides a lot of information
> currently shown in xm info, I didn't found any interface for that in
> libxenlight. Is it OK to implement it? Or shall I call xc_version()
> directly from xl.c?

i think it would be nice to have a easy user interface that do a bunch
of xc_version calls and put them in a structure ready to be processed.

> I agree that the whole effort is probably not worth the gains.
> Especially since we have only one library one could update this together
> with the tools. If we came to some kind of stable interface, one could
> use the standard UNIX library versioning scheme.
> The only question is if we can keep pace with the hypervisor
> development. If it introduces new features, hypercalls, extended
> structures do we really want to break compatibility or do we refrain
> from implementing new features?

my take on it is, new features are more important than compat.
if it happens that we *have* to break an interface to implement a new 
feature, then it should be done; although probably trying to minimize 
the disruption is probably a good idea.

> I suppose that at least in the -unstable tree we don't care about
> compatibility and only keep a stable interface in the -testing trees,
> the libxl version could then be named after the stable hypervisor version.

hmm. I think even in unstable, we would try to keep compat as possible.
not sure what the policy with testing is going to be.

-- 
Vincent