From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48349) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qv80z-0008Nm-D1 for qemu-devel@nongnu.org; Sun, 21 Aug 2011 09:24:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qv80x-0004Hm-Q1 for qemu-devel@nongnu.org; Sun, 21 Aug 2011 09:24:37 -0400 Received: from mail-yx0-f173.google.com ([209.85.213.173]:49202) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qv80x-0004Hd-NV for qemu-devel@nongnu.org; Sun, 21 Aug 2011 09:24:35 -0400 Received: by yxt3 with SMTP id 3so3631148yxt.4 for ; Sun, 21 Aug 2011 06:24:34 -0700 (PDT) Message-ID: <4E510710.6000009@codemonkey.ws> Date: Sun, 21 Aug 2011 08:24:32 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1313689697-23627-1-git-send-email-avi@redhat.com> <4E4E7FCE.5050108@redhat.com> <4E50774B.9030901@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] Wire g_new() and friends to the qemu_malloc() family List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Peter Maydell , Avi Kivity , qemu-devel@nongnu.org On 08/21/2011 02:17 AM, Blue Swirl wrote: > On Sun, Aug 21, 2011 at 3:11 AM, Anthony Liguori wrote: >> On 08/20/2011 01:59 AM, Blue Swirl wrote: >>> >>> On Fri, Aug 19, 2011 at 3:22 PM, Avi Kivity wrote: >>>> >>>> On 08/18/2011 09:54 PM, Peter Maydell wrote: >>>>> >>>>> On 18 August 2011 18:48, Avi Kivity wrote: >>>>>> >>>>>> +static GMemVTable gmemvtable = { >>>>>> + .malloc = qemu_malloc, >>>>>> + .realloc = qemu_realloc, >>>>>> + .free = qemu_free, >>>>>> +}; >>>>>> + >>>>>> +/** >>>>>> + * qemu_malloc_init: initialize memory management >>>>>> + */ >>>>>> +void qemu_malloc_init(void) >>>>>> +{ >>>>>> + g_mem_set_vtable(&gmemvtable); >>>>>> +} >>>>> >>>>> Does this mean you can now safely allocate with g_malloc >>>>> and free with qemu_free, or is mixing the two APIs like that >>>>> still a no-no ? >>>> >>>> You can, but I'd forbid it. Mixing layers can only lead to tears later >>>> on. >>>> >>>> Best would be to convert qemu_malloc()s to g_new()s and g_malloc()s to >>>> reduce confusion. >>> >>> Also plain malloc() and friends, except in tracing back end for obvious >>> reasons. >> >> sed script: >> >> s:qemu_mallocz\( *\)(:g_malloc0\1\(:g >> s:qemu_malloc\( *\)(:g_malloc\1\(:g >> s:qemu_free\( *\)(:g_free\1\(:g >> s:qemu_strdup\( *\)(:g_strdup\1\(:g >> s:qemu_strndup\( *\)(:g_strndup\1\(:g > > nih--; > > Too bad GLib does not provide a function which gives aligned memory, > then also qemu_memalign() and maybe qemu_vmalloc() could be replaced. Indeed :-/ > > The next step (or merged with this step) should be to replace plain > libc malloc/free/asprintf/strdup with > g_malloc/g_free/g_strdup_printf/g_strdup. There's not a lot of these but they need to be audited individual to make sure that the frees correspond to mallocs. > > HACKING should be updated to refer to g_* versions instead of qemu_* functions. That's included in the series. >> It takes a little build magic too to make sure everything has access to >> glib. >> >> The patch is way too large to post. Please speak now if you have an >> objection otherwise I'll commit in a couple days. >> >> http://repo.or.cz/w/qemu/aliguori.git/commit/5cc99cedb46b3916dae8a565d5ffc5fb2f2e9bd6 >> >> If anyone wants to try it out first. > > I didn't test it but looks reasonable. I've pushed so qemu_malloc is no more. Regards, Anthony Liguori