From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:37863)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <wency@cn.fujitsu.com>) id 1SBzCn-000669-Uv
	for qemu-devel@nongnu.org; Sun, 25 Mar 2012 21:58:47 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <wency@cn.fujitsu.com>) id 1SBzCm-0007Aw-0s
	for qemu-devel@nongnu.org; Sun, 25 Mar 2012 21:58:45 -0400
Received: from [222.73.24.84] (port=18776 helo=song.cn.fujitsu.com)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <wency@cn.fujitsu.com>) id 1SBzCl-0007Ag-LZ
	for qemu-devel@nongnu.org; Sun, 25 Mar 2012 21:58:43 -0400
Message-ID: <4F6FCDD6.3010902@cn.fujitsu.com>
Date: Mon, 26 Mar 2012 10:00:54 +0800
From: Wen Congyang <wency@cn.fujitsu.com>
MIME-Version: 1.0
References: <4F680037.9090101@cn.fujitsu.com>	<20120323.170622.115912902.d.hatayama@jp.fujitsu.com>
	<20120323140737.28265fae@doriath.home>
In-Reply-To: <20120323140737.28265fae@doriath.home>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [Qemu-devel] [PATCH 11/11 v10] introduce a new monitor command
 'dump-guest-memory' to dump guest's memory
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: Luiz Capitulino <lcapitulino@redhat.com>
Cc: jan.kiszka@siemens.com, qemu-devel@nongnu.org, HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>, anderson@redhat.com, anthony@codemonkey.ws, eblake@redhat.com

At 03/24/2012 01:07 AM, Luiz Capitulino Wrote:
> On Fri, 23 Mar 2012 17:06:22 +0900 (   )
> HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> wrote:
> 
>> From: Wen Congyang <wency@cn.fujitsu.com>
>> Subject: [PATCH 11/11 v10] introduce a new monitor command 'dump-guest-memory' to dump guest's memory
>> Date: Tue, 20 Mar 2012 11:57:43 +0800
>>
>> <cut>
>>
>>> +typedef struct DumpState {
>>> +    ArchDumpInfo dump_info;
>>> +    MemoryMappingList list;
>>> +    uint16_t phdr_num;
>>> +    uint32_t sh_info;
>>> +    bool have_section;
>>> +    bool resume;
>>> +    target_phys_addr_t memory_offset;
>>> +    write_core_dump_function f;
>>
>> f() is so general. Type information is meaningless enough, but there's
>> no explicit occurence of the function call of f(). Could you consider
>> renaming?
> 
> Agreed. I actually don't see why this indirection is needed.
> 

Currently, we only support to write to fd. So this indirection isn't needed.
If we want to write the memory to other place, this indirection may be needed.
I will remove it as it isn't needed now. But the code in target-i386/arch_dump.c
will still use write_core_dump_function.

Thanks
Wen Congyang