From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:53198)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <famz@redhat.com>) id 1XwQzc-0001Dz-DU
	for qemu-devel@nongnu.org; Thu, 04 Dec 2014 02:38:34 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <famz@redhat.com>) id 1XwQzW-00048g-8W
	for qemu-devel@nongnu.org; Thu, 04 Dec 2014 02:38:28 -0500
Received: from mx1.redhat.com ([209.132.183.28]:36989)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <famz@redhat.com>) id 1XwQzW-00048a-1N
	for qemu-devel@nongnu.org; Thu, 04 Dec 2014 02:38:22 -0500
Date: Thu, 4 Dec 2014 15:38:12 +0800
From: Fam Zheng <famz@redhat.com>
Message-ID: <20141204073811.GA12967@ad.nay.redhat.com>
References: <1416991272-10277-1-git-send-email-bdpayne@acm.org>
	<1417033667-10364-1-git-send-email-bdpayne@acm.org>
	<1417033667-10364-2-git-send-email-bdpayne@acm.org>
	<20141127020403.GA7921@fam-t430.nay.redhat.com>
	<CAFpPvXDLHzS-BuNvrONhAqEy9khV-MeKFL_TXO3kG=GSm2bYog@mail.gmail.com>
	<20141204045733.GA25575@ad.nay.redhat.com>
	<CAFpPvXAHNmkb15fdkfv0q-ZiQFdqw9PxPuRrgYM7GaoFkzMmMg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAFpPvXAHNmkb15fdkfv0q-ZiQFdqw9PxPuRrgYM7GaoFkzMmMg@mail.gmail.com>
Subject: Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write
 access to physical 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: "Bryan D. Payne" <bdpayne@acm.org>
Cc: qemu-devel@nongnu.org, lcapitulino@redhat.com

On Wed, 12/03 22:28, Bryan D. Payne wrote:
> >
> > It is critical as a transport data structure. You have to define a
> > byte-by-byte
> > layout (concerning endianness and padding) and use padding fields together
> > with
> > QEMU_PACKED, so the representation is not dependent on alignment
> 
> 
> This makes sense for network protocols.  But, in this case, the protocol is
> always taking placing over a unix socket on the localhost.  This is why I
> wasn't sure that it was necessary.
> 
> Just to be clear... the QMP connection could go over the network, but its
> only purpose is to set up the unix socket on the local machine (meaning
> that doing it over the network is kind of pointless, even if it is
> possible).  Once the unix socket is setup, the memory access protocol
> happens over that socket.

This doesn't stop the client from using a different alignment than we expect.
It's necessary to be explicit as a binary protocol.

Fam