From: Anthony Liguori <anthony@codemonkey.ws>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Avi Kivity <avi@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] Wire g_new() and friends to the qemu_malloc() family
Date: Sun, 21 Aug 2011 08:24:32 -0500 [thread overview]
Message-ID: <4E510710.6000009@codemonkey.ws> (raw)
In-Reply-To: <CAAu8pHsqcpzzVctoeSXQ3XvGShqCVMAY1xD59WSHe1Kadei8tg@mail.gmail.com>
On 08/21/2011 02:17 AM, Blue Swirl wrote:
> On Sun, Aug 21, 2011 at 3:11 AM, Anthony Liguori<anthony@codemonkey.ws> wrote:
>> On 08/20/2011 01:59 AM, Blue Swirl wrote:
>>>
>>> On Fri, Aug 19, 2011 at 3:22 PM, Avi Kivity<avi@redhat.com> wrote:
>>>>
>>>> On 08/18/2011 09:54 PM, Peter Maydell wrote:
>>>>>
>>>>> On 18 August 2011 18:48, Avi Kivity<avi@redhat.com> 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
next prev parent reply other threads:[~2011-08-21 13:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-18 17:48 [Qemu-devel] [PATCH] Wire g_new() and friends to the qemu_malloc() family Avi Kivity
2011-08-19 4:25 ` Stefan Hajnoczi
2011-08-19 4:54 ` Peter Maydell
2011-08-19 15:22 ` Avi Kivity
2011-08-20 6:59 ` Blue Swirl
2011-08-21 3:11 ` Anthony Liguori
2011-08-21 7:17 ` Blue Swirl
2011-08-21 13:24 ` Anthony Liguori [this message]
2011-08-22 6:53 ` Paolo Bonzini
2011-08-21 3:40 ` Anthony Liguori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E510710.6000009@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=avi@redhat.com \
--cc=blauwirbel@gmail.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).