Re: [Xen-devel] future plans for libxl?

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Andre Przywara writes ("Re: [Xen-devel] future plans for libxl?"):
> 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.

I would suggest that you should decide how you want to do it, but you
should feel free to submit patches against libxl to implement the
features you need - just as you would submit patches for the
hypervisor.

At some point soon we're going to be strongly encouraging people who
provide new features to do so via libxl (rather than, or in addition
to, xend).

> 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?

In general, if there are interfaces missing then they should be added.
A user of libxl should not need to call libxc directly.  So yes, it
would be good to have a way to get the information provided by the
XENVER hypercall and xc_version.

Perhaps rather than expecting the libxl caller to include
xen/include/public/version.h, it would be better to have a single
libxc call that fills in a single structure by making all the relevant
calls and copying the data out.

Vincent, Stefano, what do you think ?

> [...]  If it introduces new features, hypercalls, extended 
> structures do we really want to break compatibility or do we refrain 
> >from implementing new features?

I think the plan is that we will break binary compatibility at Xen
releases.

> 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.

Exactly.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel