[ANNOUNCE] libxenlight

[ANNOUNCE] libxenlight

[Stefano Stabellini]

Hi all,

I am pleased to announce "libxenlight", a new small and lightweight C
library that refactors existing code in a coherent and easy to use API
to interface to the hypervisor and xenstore to perform operations such
as domain creation and destruction, suspend/restore and pci passthrough.

The goals of libxenlight are:

- be easy to use and to extend
- provide a simple and robust API for tool stacks to do xen operations
- create a common codebase for the lower-level implementation of all the
  various xen tool stacks

At the moment libxenlight implements domain creation, destruction and
list domains; next items on the roadmap are suspend, resume and pci
passthrough.
Libxenlight has been tested only on Linux but we would like to make it
work on other systems as well.
To aid development and testing we have created a small command line
utility called "xl" that invokes the API.

We believe there is significant value in having all the various tool
stacks (xend, xapi, xenvm, libvirt etc) use a common lower-layer, and so
hope developers will embrace this project, contribute to it, and move
their favoured stack over to using it.

Cheers,
Stefano Stabellini

Re: [ANNOUNCE] libxenlight

[Jun Koi]

Hi Stefano,

Is this yet-another-GPL lib? If so, that is really disappointed.

I think people desperately need LGPL code like this, but not GPL. So
please make it LGPL for people to use.

Personally, I have some small projects, and I had to reimplement a
part of libxc under LGPL. If libxenlight is under LGPL, I dont have to
waste my time doing that.

I believe that libvirt doesnt want this code, because of
incompatibility issue: libvirt is LGPL, which is more free, IMO.

Thanks,
Jun

On Mon, Nov 9, 2009 at 11:04 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> Hi all,
>
> I am pleased to announce "libxenlight", a new small and lightweight C
> library that refactors existing code in a coherent and easy to use API
> to interface to the hypervisor and xenstore to perform operations such
> as domain creation and destruction, suspend/restore and pci passthrough.
>
> The goals of libxenlight are:
>
> - be easy to use and to extend
> - provide a simple and robust API for tool stacks to do xen operations
> - create a common codebase for the lower-level implementation of all the
>  various xen tool stacks
>
> At the moment libxenlight implements domain creation, destruction and
> list domains; next items on the roadmap are suspend, resume and pci
> passthrough.
> Libxenlight has been tested only on Linux but we would like to make it
> work on other systems as well.
> To aid development and testing we have created a small command line
> utility called "xl" that invokes the API.
>
> We believe there is significant value in having all the various tool
> stacks (xend, xapi, xenvm, libvirt etc) use a common lower-layer, and so
> hope developers will embrace this project, contribute to it, and move
> their favoured stack over to using it.
>
> Cheers,
> Stefano Stabellini
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

Re: [ANNOUNCE] libxenlight

[Vincent Hanquez]

Jun Koi wrote:
> Hi Stefano,
>
> Is this yet-another-GPL lib? If so, that is really disappointed.
>
>   
> I think people desperately need LGPL code like this, but not GPL. So
> please make it LGPL for people to use.
>
> Personally, I have some small projects, and I had to reimplement a
> part of libxc under LGPL. If libxenlight is under LGPL, I dont have to
> waste my time doing that.
>
> I believe that libvirt doesnt want this code, because of
>   
> incompatibility issue: libvirt is LGPL, which is more free, IMO.
>   
Hi Jun,

The library by itself is released under the LGPLv2 license. However, 
since it's linked to the xenguest and xencontrol libraries which are 
both GPLv2, you cannot use it in a LGPL context yet, but only in a GPL 
context (unless you can replace all xenguest/xc calls to some libraries 
of your own).

we do have another implementation of libxc that is LGPL (rewritten from 
scratch) that is available in the xencloud api-libs tree. however a 
reimplemented version (or relicensed version) of xenguest is still 
missing for now.

-- 
Vincent

Re: [ANNOUNCE] libxenlight

[Ian Jackson]

Jun Koi writes ("Re: [Xen-devel] [ANNOUNCE] libxenlight"):
> I believe that libvirt doesnt want this code, because of
> incompatibility issue: libvirt is LGPL, which is more free, IMO.

libvirt is the library for talking to virt-manager and so doesn't need
to link to libxl or indeed any of the GPL'd libraries such as
libxenguest.  So there is no problem here.

> Is this yet-another-GPL lib? If so, that is really disappointed.

In any case, donning a personal hat for a moment, there is nothing
wrong with releasing a library under the full GPL.  Whether to do so
is a political and strategic decision like many other choices of
licence.

It's fair enough to argue one way or the other about licences but
there is no general rule that the Lesser GPL should be used for a
library.

Ian.

Re: [ANNOUNCE] libxenlight

[Tim Post]

On Mon, 2009-11-09 at 17:41 +0000, Ian Jackson wrote:
> > Is this yet-another-GPL lib? If so, that is really disappointed.
> 
> In any case, donning a personal hat for a moment, there is nothing
> wrong with releasing a library under the full GPL.  Whether to do so
> is a political and strategic decision like many other choices of
> licence.

Its also a no brainer. When you combine libraries, the most restrictive
license in the mix prevails. 

> 
> It's fair enough to argue one way or the other about licences but
> there is no general rule that the Lesser GPL should be used for a
> library.

That is subjective, to a degree. If libxc was (three clause) BSD and
libxl was released GPL3 .. it would be an entirely different story for
some.

You probably remember the whole editline() / readline() fiasco when
various shells were competing for the best usability. If someone wants
the library code bad enough under a less restrictive license, they will
write and (perhaps) release it with a functionally compatible interface.

The least restrictive license, for libraries is almost always the better
idea .. for the above reason alone, unless the purpose is purely
political.

I'm not being antagonistic and I do understand why the GPL was chosen.
I'm just citing a source of possibly 'heated' confusion, its not the
first time this has come up.

Regards,
--Tim

-- 
Monkey + Typewriter = Echoreply ( http://echoreply.us )

Re: [ANNOUNCE] libxenlight

[Pasi Kärkkäinen]

On Mon, Nov 09, 2009 at 02:04:09PM +0000, Stefano Stabellini wrote:
> Hi all,
> 
> I am pleased to announce "libxenlight", a new small and lightweight C
> library that refactors existing code in a coherent and easy to use API
> to interface to the hypervisor and xenstore to perform operations such
> as domain creation and destruction, suspend/restore and pci passthrough.
> 
> The goals of libxenlight are:
> 
> - be easy to use and to extend
> - provide a simple and robust API for tool stacks to do xen operations
> - create a common codebase for the lower-level implementation of all the
>   various xen tool stacks
> 
> At the moment libxenlight implements domain creation, destruction and
> list domains; next items on the roadmap are suspend, resume and pci
> passthrough.
> Libxenlight has been tested only on Linux but we would like to make it
> work on other systems as well.
> To aid development and testing we have created a small command line
> utility called "xl" that invokes the API.
> 
> We believe there is significant value in having all the various tool
> stacks (xend, xapi, xenvm, libvirt etc) use a common lower-layer, and so
> hope developers will embrace this project, contribute to it, and move
> their favoured stack over to using it.
> 

Hello,

Does libxenlight currently work on both the traditional Xen and XCP?

I assume XCP is using the ocaml implementation of xenstore, so does that
make any difference? I guess the hypervisors are close enough at least.

-- Pasi

Re: [ANNOUNCE] libxenlight

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 2100 bytes --]

On Thu, 19 Nov 2009, Pasi Kärkkäinen wrote:
> On Mon, Nov 09, 2009 at 02:04:09PM +0000, Stefano Stabellini wrote:
> > Hi all,
> > 
> > I am pleased to announce "libxenlight", a new small and lightweight C
> > library that refactors existing code in a coherent and easy to use API
> > to interface to the hypervisor and xenstore to perform operations such
> > as domain creation and destruction, suspend/restore and pci passthrough.
> > 
> > The goals of libxenlight are:
> > 
> > - be easy to use and to extend
> > - provide a simple and robust API for tool stacks to do xen operations
> > - create a common codebase for the lower-level implementation of all the
> >   various xen tool stacks
> > 
> > At the moment libxenlight implements domain creation, destruction and
> > list domains; next items on the roadmap are suspend, resume and pci
> > passthrough.
> > Libxenlight has been tested only on Linux but we would like to make it
> > work on other systems as well.
> > To aid development and testing we have created a small command line
> > utility called "xl" that invokes the API.
> > 
> > We believe there is significant value in having all the various tool
> > stacks (xend, xapi, xenvm, libvirt etc) use a common lower-layer, and so
> > hope developers will embrace this project, contribute to it, and move
> > their favoured stack over to using it.
> > 
> 
> Hello,
> 
> Does libxenlight currently work on both the traditional Xen and XCP?

XCP is based on xen 3.4 while libxenlight is developed and tested on
xen-unstable so I doubt that in the current state it would work.
However when XCP rebases on xen 3.5 it will inherit libxenlight
automatically.
In any case backporting libxenlight to xen 3.4 shouldn't be difficult
at all.


> I assume XCP is using the ocaml implementation of xenstore, so does that
> make any difference? I guess the hypervisors are close enough at least.

The xenstore implementation doesn't make any difference, the hypervisor
changes shouldn't create any problem, but few patches in the qemu
patchqueue might.

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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