mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-12-23 21:34:54 +03:00
07613d2020
by running this command: git ls-files -z | xargs -0 perl -pi -0777 -e 's/\n\n+$/\n/' This is in preparation for a more strict make syntax-check rule that will detect trailing blank lines.
101 lines
3.8 KiB
Plaintext
101 lines
3.8 KiB
Plaintext
|
|
About a libxen library
|
|
======================
|
|
|
|
Functional description:
|
|
-----------------------
|
|
|
|
Small C library to be able to control Xen Linux guest, i.e.
|
|
provide the following operations for Xen guest domains running Linux
|
|
from domain 0 code linked to the library (running as root):
|
|
- start
|
|
- stop
|
|
- suspend
|
|
- resume
|
|
- monitor
|
|
More advanced features should be allowed as future extensions, but
|
|
are not expected to be provided in first shipment.
|
|
|
|
Open enough Licence that customers can link their apps to it (LGPL)
|
|
|
|
Small and contained enough that we can use it as a way to
|
|
provide API and ABI stability in spite if the evolution of Xen
|
|
existing API and hypervisor calls.
|
|
|
|
The current state of Xen userland:
|
|
----------------------------------
|
|
|
|
the existing Xen 3.0 userland code is mostly based on tiny C functions
|
|
using direct hypervisor calls (or /proc/xen/ interfaces) and a lot of
|
|
Python code on top driving the hypervisor.
|
|
The C code is relatively hairy, functions with 10 parameters or more
|
|
are not uncommon, and it is very low level usually without comment about
|
|
the function or its arguments. They are usually only called once in the
|
|
whole tree by the python bindings. In essence it looks like the Xen project
|
|
was not implemented with the idea of reusing that part of the code by
|
|
applications.
|
|
Indeed most of the userland code coming with Xen is built on Python,
|
|
like xend the xen daemon running on domain 0 or the xenstored daemon which
|
|
manage the state of the domains launched.
|
|
|
|
Rebuilding a library ?:
|
|
-----------------------
|
|
|
|
Providing a library at the C level to drive domain execution is in a
|
|
very large part a rimplementation of existing code but in a different way
|
|
and somehow with different goals for the code. The existing Licence (GPL)
|
|
makes it uneasy, we can't copy GPL code to put it in a LGPL'ed library,
|
|
and rewriting everything while looking at the Xen code will inevitably
|
|
lead to code similarities especially with this kind of system code. Plus
|
|
we will still need to run xend and probably xenstored to not diverge
|
|
completely from Xen existing code base.
|
|
|
|
The IBM way:
|
|
------------
|
|
|
|
Here is supposition about code that I can't instanciate except by looking
|
|
at said code but it looks that IBM also needed a C programmatic API to
|
|
manage the Xen domain definitions. Their solution was to build (Rusty
|
|
Russell did this) an LGPL C API connecting directly to the xenstore
|
|
daemon (./tools/xenstore/*). In a way this is quite more fragile as it depends
|
|
on the whole existing stack of the Xen code, but it isolate the API
|
|
from the implementation details of the current Xen source (API in
|
|
./tools/xenstore/xs.h). The goal seems to be more about testing and controlling
|
|
the xen store daemon, but it shows a different approach to decouple client
|
|
API/ABI from the Xen existing code.
|
|
|
|
Open question:
|
|
---------------
|
|
|
|
To what extent should libxen be a rewrite or an isolation layer around
|
|
some of the existing code ?
|
|
|
|
Rewrite:
|
|
|
|
Pros:
|
|
- avoid the GPL Licence problem potentially more users
|
|
- allow do build a cleaner more stable layer
|
|
- the existing code is frightening
|
|
Cons:
|
|
- awful lot of work debugging very hard
|
|
- will still require existing Xen code to be running
|
|
- splitting interfaces is hard politically and lower the
|
|
Open Source efforts toward the project
|
|
|
|
Wrappers on top of existing code:
|
|
|
|
Pros:
|
|
- much smaller code rewrite
|
|
- benefits from the bugfixes injected by other patchers upstream
|
|
Cons:
|
|
- Licence constraint GPL only for apps
|
|
- API/ABI isolation may not be easier in that way
|
|
|
|
Potentially the API could be implemented as a layer on top of the existing
|
|
libxc C code library and then progressively migrating out the existing
|
|
dependence to Xen code as the interfaces stabilize.
|
|
|
|
Daniel Veillard <veillard@redhat.com>
|
|
|
|
Mon Oct 24 18:40:19 CEST 2005
|