mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2025-01-11 15:27:47 +00:00
cfbe9f1201
Add the main glib.h to internal.h so that all common code can use it.
Historically glib allowed applications to register an alternative
memory allocator, so mixing g_malloc/g_free with malloc/free was not
safe.
This was feature was dropped in 2.46.0 with:
commit 3be6ed60aa58095691bd697344765e715a327fc1
Author: Alexander Larsson <alexl@redhat.com>
Date: Sat Jun 27 18:38:42 2015 +0200
Deprecate and drop support for memory vtables
Applications are still encourged to match g_malloc/g_free, but it is no
longer a mandatory requirement for correctness, just stylistic. This is
explicitly clarified in
commit 1f24b36607bf708f037396014b2cdbc08d67b275
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Thu Sep 5 14:37:54 2019 +0100
gmem: clarify that g_malloc always uses the system allocator
Applications can still use custom allocators in general, but they must
do this by linking to a library that replaces the core malloc/free
implemenentation entirely, instead of via a glib specific call.
This means that libvirt does not need to be concerned about use of
g_malloc/g_free causing an ABI change in the public libary, and can
avoid memory copying when talking to external libraries.
This patch probes for glib, which provides the foundation layer with
a collection of data structures, helper APIs, and platform portability
logic.
Later patches will introduce linkage to gobject which provides the
object type system, built on glib, and gio which providing objects
for various interesting tasks, most notably including DBus client
and server support and portable sockets APIs, but much more too.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
||
|---|---|---|
| .. | ||
| Makefile.inc.am | ||
| README | ||
| vbox_CAPI_v5_0.h | ||
| vbox_CAPI_v5_1.h | ||
| vbox_CAPI_v5_2.h | ||
| vbox_common.c | ||
| vbox_common.h | ||
| vbox_driver.c | ||
| vbox_driver.h | ||
| vbox_get_driver.h | ||
| vbox_glue.c | ||
| vbox_glue.h | ||
| vbox_MSCOMGlue.c | ||
| vbox_MSCOMGlue.h | ||
| vbox_network.c | ||
| vbox_snapshot_conf.c | ||
| vbox_snapshot_conf.h | ||
| vbox_storage.c | ||
| vbox_tmpl.c | ||
| vbox_uniformed_api.h | ||
| vbox_V5_0.c | ||
| vbox_V5_1.c | ||
| vbox_V5_2.c | ||
| vbox_XPCOMCGlue.c | ||
| vbox_XPCOMCGlue.h | ||
| virtvboxd.service.in | ||
Licensing
Note that much of the vbox in this directory is LGPLv2-only. Thus, it
cannot be linked into any software that also wants to use GPLv3+ code.
This readme file is:
Copyright (C) 2009, 2013 Red Hat, Inc.
Copying and distribution of this file, with or without modification,
are permitted in any medium without royalty provided the copyright
notice and this notice are preserved. This file is offered as-is,
without warranty of any kind.
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 contains all version specified codes. It implements the
vboxUniformedAPI for each vbox version.
vbox_common.c
The file implement the common driver, with the uniformed api which
defined in vbox_uniformed_api.h and implemented in vbox_tmpl.c
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.