|
xen-devel
Re: [Xen-devel] future plans for libxl?
|
Are there any plans for python bindings for libxl?
I could probably do something up with ctypes, but I assume the ABI isnt at all stable to do that yet. On 15 April 2010 08:21, Andre Przywara <andre.przywara@xxxxxxx> 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?
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home