Re: future plans for libxl?

[Andre Przywara <andre.przywara@amd.com>]

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?
2.) I see a simple check of LIBXL_VERSION when doing libxl_ctx_init(). 
Is that meant to be that hard or is a compatibility scheme planned 
(like: support apps using on older interface and somehow emulate it?)

> 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?

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

> Even though xend will be ported to libxenlight, xl is going to be
> smaller and well tested, therefore we encourage people that don't need
> advanced xend features, like managed domains or the XML RPC interface,
> to use xl.
That is good to know. We often have issue with xend not starting for 
this or that reason, hope that will be easier in the future.

Regards,
Andre.

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.

-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 448-3567-12