From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:35342)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <wency@cn.fujitsu.com>) id 1ZexCz-0005nM-Jk
	for qemu-devel@nongnu.org; Wed, 23 Sep 2015 23:28:34 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <wency@cn.fujitsu.com>) id 1ZexCw-0006j6-Bu
	for qemu-devel@nongnu.org; Wed, 23 Sep 2015 23:28:33 -0400
Received: from [59.151.112.132] (port=21469 helo=heian.cn.fujitsu.com)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <wency@cn.fujitsu.com>) id 1ZexCv-0006iD-UO
	for qemu-devel@nongnu.org; Wed, 23 Sep 2015 23:28:30 -0400
References: <20150923202200.6569.64538.stgit@gimli.home>
	<20150923202358.6569.29219.stgit@gimli.home>
	<560365F6.1060000@cn.fujitsu.com>
	<1443064948.23936.528.camel@redhat.com>
From: Wen Congyang <wency@cn.fujitsu.com>
Message-ID: <56036DBF.7090204@cn.fujitsu.com>
Date: Thu, 24 Sep 2015 11:27:59 +0800
MIME-Version: 1.0
In-Reply-To: <1443064948.23936.528.camel@redhat.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PULL 10/19] vfio/pci: Foundation for new quirk
 structure
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: qemu-devel@nongnu.org

On 09/24/2015 11:22 AM, Alex Williamson wrote:
> On Thu, 2015-09-24 at 10:54 +0800, Wen Congyang wrote:
>> On 09/24/2015 04:23 AM, Alex Williamson wrote:
>>> @@ -275,12 +276,15 @@ static void vfio_vga_probe_ati_3c3_quirk(VFIOPCIDevice *vdev)
>>>      }
>>>  
>>>      quirk = g_malloc0(sizeof(*quirk));
>>> -    quirk->vdev = vdev;
>>> +    legacy = quirk->data = g_malloc0(sizeof(*legacy));
>>> +    quirk->mem = legacy->mem = g_malloc0_n(sizeof(MemoryRegion), 1);
>>
>> Why do you use g_malloc0_n() here? It is introduced in glib 2.24, but we only require glib 2.22.
> 
> Because I saw it, I guess in scripts/coverity-model.c, and used it.  In
> this particular instance it seems irrelevant, but VFIOQuirk.mem points
> to an array of MemoryRegions, other users here have more than one array
> entry and I chose to use the same allocator throughout for consistency.
> What's the preferred helper here, simply calloc()?  Thanks,

Yes, there is g_malloc0_n() in scripts/coverity-model.c. But it still breaks
building. calloc()? I guess we don't use it directly in qemu.

g_malloc0_n ()

gpointer
g_malloc0_n (gsize n_blocks,
             gsize n_block_bytes);

This function is similar to g_malloc0(), allocating (n_blocks * n_block_bytes ) bytes, but care is taken to detect possible overflow during multiplication.

So I think we can use g_malloc0(sizeof(MemoryRegion) * n).

Thanks
Wen Congyang

> 
> Alex
> 
> .
>