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

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