mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-11-02 03:11:12 +00:00
aa14709a47
The drivers were accepting domain configs without checking if those were actually meant for them. For example the LXC driver happily accepts configs with type QEMU. Add a check for the expected domain types to the virDomainDefParse* functions. |
||
|---|---|---|
| .. | ||
| README | ||
| vbox_CAPI_v2_2.h | ||
| vbox_CAPI_v3_0.h | ||
| vbox_CAPI_v3_1.h | ||
| vbox_CAPI_v3_2.h | ||
| vbox_CAPI_v4_0.h | ||
| vbox_driver.c | ||
| vbox_driver.h | ||
| vbox_glue.c | ||
| vbox_glue.h | ||
| vbox_MSCOMGlue.c | ||
| vbox_MSCOMGlue.h | ||
| vbox_tmpl.c | ||
| vbox_V2_2.c | ||
| vbox_V3_0.c | ||
| vbox_V3_1.c | ||
| vbox_V3_2.c | ||
| vbox_V4_0.c | ||
| vbox_XPCOMCGlue.c | ||
| vbox_XPCOMCGlue.h | ||
Explanation about the how multi-version support
for VirtualBox libvirt driver is implemented.
Since VirtualBox adds multiple new features for each release, it is but
natural that the C API which VirtualBox exposes is volatile across
versions and thus needs a good mechanism to handle multiple versions
during runtime. The solution was something like this:
Firstly the file structure is as below:
vbox_CAPI_v2_2.h
vbox_XPCOMCGlue.h
vbox_XPCOMCGlue.c
These files are C API/glue code files directly taken from the
VirtualBox OSE source and is needed for C API to work as expected.
vbox_driver.h
vbox_driver.c
These files have the main logic for registering the virtualbox driver
with libvirt.
vbox_V2_2.c
The file which has version dependent changes and includes the template
file for given below for all of its functionality.
vbox_tmpl.c
The file where all the real driver implementation code exists.
Now there would be a vbox_V*.c file (for eg: vbox_V2_2.c for V2.2) for
each major virtualbox version which would do some preprocessor magic
and include the template file (vbox_tmpl.c) in it for the functionality
it offers.