[libvirt] [PATCH v2 02/23] build: link to glib library

[Ján Tomko]

On Mon, Oct 07, 2019 at 06:14:04PM +0100, Daniel P. Berrangé wrote:
>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 at 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 at 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.
>
>Reviewed-by: Pavel Hrdina <phrdina at redhat.com>
>Signed-off-by: Daniel P. Berrangé <berrange at redhat.com>
>---
> docs/hacking.html.in       | 21 +++++++++++++++++++++
> src/Makefile.am            |  2 ++
> src/internal.h             |  1 +
> src/lxc/Makefile.inc.am    |  2 ++
> src/remote/Makefile.inc.am |  1 +
> src/util/Makefile.inc.am   |  1 +
> tests/Makefile.am          |  3 ++-
> tools/Makefile.am          |  1 +
> 8 files changed, 31 insertions(+), 1 deletion(-)
>
>diff --git a/docs/hacking.html.in b/docs/hacking.html.in
>index edf2f54ce3..93b451591e 100644
>--- a/docs/hacking.html.in
>+++ b/docs/hacking.html.in
>@@ -989,6 +989,27 @@ BAD:
>       it points to, or it is aliased to another pointer that is.
>     </p>
>
>+    <h2><a id="glib">Adoption of GLib APIs</a></h2>
>+

Trailing whitespace at the end of this line ^^

>+    <p>
>+      Libvirt has adopted use of the
>+      <a href="https://developer.gnome.org/glib/stable/">GLib library</a>.
>+      Due to libvirt's long history of development, there are many APIs
>+      in libvirt, for which GLib provides an alternative solution. The
>+      general rule to follow is that the standard GLib solution will be
>+      preferred over historical libvirt APIs. Existing code will be
>+      ported over to use GLib APIs over time, but new code should use
>+      the GLib APIs straight away where possible.
>+    </p>
>+
>+    <p>
>+      The following is a list of libvirt APIs that should no longer be
>+      used in new code, and their suggested GLib replacements:
>+    </p>
>+
>+    <dl>
>+    </dl>
>+
>     <h2><a id="memalloc">Low level memory management</a></h2>
>
>     <p>

Reviewed-by: Ján Tomko <jtomko at redhat.com>

Jano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20191008/0cc07c40/attachment-0001.sig>