| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] future plans for libxl?
Andre Przywara writes ("Re: [Xen-devel] future plans for libxl?"):
> 1.) Is there a fixed interface for libxenlight? I see libxc interfaces
> duplicated (like {xc,libxl_get}_physinfo), is that thought to provide a
> more stable interface than xc does (which changed quite a bit lastly).
We intend libxl to have a reasonably stable API. It won't have a
stable ABI because that's a lot of work. Instead we'll just bump the
library soname each release just as we do for the underlying
libraries.
> What about extending this interface? For complete xl info I need more
> field of the physinfo sysctl to be provided by libxl_get_physinfo, is it
> OK to extend the struct libxl_physinfo?
Yes.
> 2.) I see a simple check of LIBXL_VERSION when doing libxl_ctx_init().
> Is that meant to be that hard or is a compatibility scheme planned
> (like: support apps using on older interface and somehow emulate it?)
I don't think we have the effort to do a compatibility scheme.
Personally I think this check is not really useful. The dynamic
linker will check our soname to avoid loading a libxl's from a
different major version of Xen.
If for some reason it is difficult to rebuild a libxl-using
application against a new libxl when a new version of Xen is released,
we will aim in general for it to be possible to continue to use the
application with the older version of libxl, although we may not
achieve this in every case.
> That sounds great. What is the timeframe for this? Currently I do xend
> code in the first run and consider libxenlight only with lower priority.
> Shall I swap this?
I would say yes. libxl is already better than xend in some important
respects and we are working to improve its quality.
Thanks for your interest.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home