Re: [Xen-devel] [libvirt] [PATCH-RFC] Change libxl to use Xen 4.2 interface

[Jim Fehlig <jfehlig@xxxxxxxx>]

Daniel P. Berrange wrote:
> On Thu, May 10, 2012 at 10:56:06AM +0100, Ian Campbell wrote:
>   
>> On Wed, 2012-05-09 at 18:13 +0100, Daniel De Graaf wrote:
>>     
>>> This patch changes libxl to use the interface in Xen 4.2. It is provided
>>> as an example, not intended to go in to libvirt as-is since it removes
>>> all support for libxl from Xen 4.1. It also still has some cruft (extra
>>> void casts on parameters) and the device model info population is not
>>> written. It has been tested with simple domain create/destroy.
>>> ---
>>>  src/libxl/libxl_conf.c   |  134 +++++++++------
>>>  src/libxl/libxl_conf.h   |    8 +-
>>>  src/libxl/libxl_driver.c |  430 
>>> ++++++++++++++++++++++++++--------------------
>>>  3 files changed, 326 insertions(+), 246 deletions(-)
>>>       
>> Thanks Daniel, interesting to see. It doesn't seem as invasive as I
>> expected given the number of changes to libxl's interfaces between 4.1
>> and 4.2. 
>>
>> I suppose it is worth mentioning in this context that we are intending
>> to maintain the 4.2 libxl API in a stable manner going forward, as
>> described near the top of:
>> http://xenbits.xen.org/hg/staging/xen-unstable.hg/file/tip/tools/libxl/libxl.h
>>
>> Since libvirt is one of the main reasons we are doing this it would be
>> useful to check that this actually meets the needs from that side.
>>     
>
> Having a long term stable API for libxl certainly gets our vote.
>
> WRT the use of LIBXL_API_VERSION to control API version. Libvirt generally
> aims to support all possible API versions, so I expect we would not want
> to define LIBXL_API_VERSION. Instead the libvirt code would #ifdef various
> bits according to the libxl version it detects.
>
>   
>> That doesn't really help with support 4.1 and 4.2+. A large portion of
>> the below looks like it would be reasonably easy to abstract away with a
>> header full of compat defines for naming changes etc, other bits don't
>> look so simple to deal with.
>>     
>
> Personally I would prefer to keep support for all 4.x versions, but I'll
> defer to Suse developers to decide upon this since they are the primary
> maintainers & users of the libxl driver.
>   

Yes, I too would like to keep support for all 4.x versions.  As pointed
out by you and Ian, it can be detected at build time vs the runtime
probing that the legacy xen libvirt driver does.

Bamvor has just started looking into this, so hopefully he can help with
the effort.

Regards,
Jim


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel