|
xen-devel
Re: [Xen-devel] future plans for libxl?
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home