From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:42647)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <valerio@aimale.com>) id 1ZpMkK-00089u-I0
	for qemu-devel@nongnu.org; Thu, 22 Oct 2015 16:46:01 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <valerio@aimale.com>) id 1ZpMkH-0001HI-CB
	for qemu-devel@nongnu.org; Thu, 22 Oct 2015 16:46:00 -0400
Received: from smtp.aimale.com ([166.78.138.199]:50629)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <valerio@aimale.com>) id 1ZpMkH-0001H5-45
	for qemu-devel@nongnu.org; Thu, 22 Oct 2015 16:45:57 -0400
References: <1444952643-5033-1-git-send-email-valerio@aimale.com>
	<87h9lrkz56.fsf@blackfin.pond.sub.org> <56210A17.6080401@aimale.com>
	<87io63xpke.fsf@blackfin.pond.sub.org> <56250035.40805@aimale.com>
	<87twpkqyow.fsf@blackfin.pond.sub.org>
	<20151022191203.GC3736@thinpad.lan.raisama.net>
	<56293F99.1060109@aimale.com> <56294121.20301@redhat.com>
From: Valerio Aimale <valerio@aimale.com>
Message-ID: <56294B01.7060401@aimale.com>
Date: Thu, 22 Oct 2015 14:45:53 -0600
MIME-Version: 1.0
In-Reply-To: <56294121.20301@redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] QEMU patch to allow VM introspection via libvmi
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: Eric Blake <eblake@redhat.com>, Eduardo Habkost <ehabkost@redhat.com>, Markus Armbruster <armbru@redhat.com>
Cc: qemu-devel@nongnu.org, lcapitulino@redhat.com

On 10/22/15 2:03 PM, Eric Blake wrote:
> On 10/22/2015 01:57 PM, Valerio Aimale wrote:
>
>> pmemmap would return the following json
>>
>> {
>>      'success' : 'true',
>>      'map_filename' : '/tmp/QEM_mmap_1234567'
>> }
> In general, it is better if the client controls the filename, and not
> qemu.  This is because things like libvirt like to run qemu in a
> highly-constrained environment, where the caller can pass in a file
> descriptor that qemu cannot itself open().  So returning a filename is
> pointless if the filename was already provided by the caller.
>
Eric, I absolutely and positively agree with you. I was just 
brainstorming. Consider my pseudo-C code as the mailing list analog of 
somebody scribbling on a white board and trying explain an idea.

I agree with you the file name should come from the qmp client.