The library.xen file contains a braindump of thoughts dating from the very first days of libvirt, when it was briefly called libxen. This is not useful and potentially misleading or confusing for people. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com&gt; --- cfg.mk | 2 +- docs/library.xen | 100 ------------------------------------------------------- 2 files changed, 1 insertion(+), 101 deletions(-) delete mode 100644 docs/library.xen diff --git a/cfg.mk b/cfg.mk index 9546853..a4305a8 100644 --- a/cfg.mk +++ b/cfg.mk @@ -1220,7 +1220,7 @@ exclude_file_name_regexp--sc_prohibit_mixed_case_abbreviations = \ ^src/(vbox/vbox_CAPI.*.h|esx/esx_vi.(c|h)|esx/esx_storage_backend_iscsi.c)$$ exclude_file_name_regexp--sc_prohibit_empty_first_line = \ - ^(README|daemon/THREADS\.txt|src/esx/README|docs/library.xen|tests/(vmwarever|virhostcpu)data/.*)$$ + ^(README|daemon/THREADS\.txt|src/esx/README|tests/(vmwarever|virhostcpu)data/.*)$$ exclude_file_name_regexp--sc_prohibit_useless_translation = \ ^tests/virpolkittest.c diff --git a/docs/library.xen b/docs/library.xen deleted file mode 100644 index 2e1b2c5..0000000 --- a/docs/library.xen +++ /dev/null @@ -1,100 +0,0 @@ - - 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(a)redhat.com&gt; - -Mon Oct 24 18:40:19 CEST 2005 -- 2.9.3