On Thu, Jan 20, 2011 at 04:49:25PM -0700, Jim Fehlig wrote:
I'm looking into creating a driver for the new Xen xl/libxl toolstack (aka libxenlight [1]), set to become the default in upcoming Xen 4.1.0 release.
My first hurdle is deciding whether this should be a new driver or integrated with existing xen-unified driver. Initially I thought a new driver would be a better approach - a clean break from the old code, similar to the xenapi driver. libxenlight is also stateless (no managed domains), which seems like another good argument for a new driver. But libxenlight is really just another interface into the same hypervisor, so in that regard it should be a xen-unified subdriver.
There are certainly benefits to the xen-unified subdriver approach, e.g. the existing hypervisor and xenstore subdrivers can be leveraged, the former providing all the capabilities code. But AFAIK, libxenlight and xend should not be used together, so I don't think we would want the xend subdriver activated if libxenlight is detected. Supposedly xl can
Seems to call for a new driver actually,
be used as a direct replacement for xm, allowing unconditional use of that subdriver.
BTW, Ian Jackson responded [2] to some of my questions regarding compatibility between old and new toolstack if you are interested.
I'd like to hear other's opinions on a new driver vs. a xen-unified subdriver.
Regards, Jim
[1] http://lists.xensource.com/archives/html/xen-devel/2009-11/msg00436.html [2] http://lists.xensource.com/archives/html/xen-devel/2010-11/msg00344.html
Hum, licencing would have to be sorted out. If this is only linked into libvirtd then using GPL only bits would be fine I guess but if directly linked into libvirt shared lib then we will have to be careful to select only LGPL libraries. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/