Re: [Xen-devel] future plans for libxl?

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 15 Apr 2010, Andre Przywara wrote:
> Stefano Stabellini wrote:
> > On Wed, 14 Apr 2010, Andre Przywara wrote:
> >> Hi,
> >>
> >> what is the current master plan for libxl?
>  >> ...
> >> Was there a mail or a document I missed already explaining this?
> >>
> > 
> > You didn't miss any email, we were planning on talking about this at
> > the next XenSummit.
> > 
> > Libxenlight is almost feature complete already: there are few things
> > missing, but not much.
> I stumbled upon missing 'info' support, so I implemented a basic version 
> of it. A few questions about it:
> 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). 
> 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?

The idea is that a client of libxenlight does not need to use any
other library (libxc, libxenguest, xenstore) directly; libxenlight
should provide all the needed functionalities.
Of course libxenlight relies on libxc, libxenguest, xenstore, etc, to
implement them.


> > Implementing the missing features and making the library rock solid are
> > our top priorities and we hope to get them done by the 4.1 release.
> > We also want to port xend and XCP to libxenlight to remove code
> > duplication and make it easier for xen and kernel developers to add new
> > features to the toolstacks.
> 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?

We hope to get the xend port done by the end of this release cycle, but in
any case libxenlight should be stable at that time, so swapping sounds
like a good idea to me.

> 
> > The xl tool is going to be the main testing tool for libxenlight and is
> > going to provide a command line interface 99% compatible with xm; once
> > libxenlight is complete and robust we would like people that currently
> > use xend, especially developers, to try out xl.
> I did, and I like it's speed (and relaxed dependency!). Although xm is 
> not that slow, xl is noticeably faster:
> brandon# time xm list
> Name           ID   Mem VCPUs      State   Time(s)
> Domain-0        0   512     1     r-----    194.5
>      0.83s real     0.17s user     0.29s system
> brandon# time xl list
> Name           ID   Mem VCPUs      State   Time(s)
> Domain-0        0   512     1        r--    194.6
>      0.02s real     0.01s user     0.02s system
> Not that speed actually matters with management tools, but it's very 
> nice to have a quickly responding interface.
> 

I am glad to hear this. We didn't do any performance test yet, so this
comes as a very good news.

> P.S. Thanks for the great work, if you need some help in any area, tell 
> the ML. Maybe a list of missing features or open issue on the Wiki is a 
> good idea.
> 
 
This is great idea, maybe if we are still in time we could even create
an entry for GSoC.

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