From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33645) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNmit-0000do-AH for qemu-devel@nongnu.org; Tue, 08 Nov 2011 09:32:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RNmio-0005Dv-Gb for qemu-devel@nongnu.org; Tue, 08 Nov 2011 09:32:23 -0500 Received: from mtagate2.uk.ibm.com ([194.196.100.162]:56731) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNmio-0005DD-9Q for qemu-devel@nongnu.org; Tue, 08 Nov 2011 09:32:18 -0500 Received: from d06nrmr1806.portsmouth.uk.ibm.com (d06nrmr1806.portsmouth.uk.ibm.com [9.149.39.193]) by mtagate2.uk.ibm.com (8.13.1/8.13.1) with ESMTP id pA8EWDBg017290 for ; Tue, 8 Nov 2011 14:32:13 GMT Received: from d06av06.portsmouth.uk.ibm.com (d06av06.portsmouth.uk.ibm.com [9.149.37.217]) by d06nrmr1806.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pA8EWD7M1753326 for ; Tue, 8 Nov 2011 14:32:13 GMT Received: from d06av06.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pA8LWDMv011923 for ; Tue, 8 Nov 2011 14:32:13 -0700 Message-ID: <4EB93D6C.9070208@linux.vnet.ibm.com> Date: Tue, 08 Nov 2011 15:32:12 +0100 From: Tim Rule MIME-Version: 1.0 References: <1320731717-903-1-git-send-email-david@gibson.dropbear.id.au> <87pqh268ee.fsf@linux.vnet.ibm.com> In-Reply-To: <87pqh268ee.fsf@linux.vnet.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] 9pfs: Stat response from server offset by 2 bytes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Aneesh Kumar K.V" Cc: rusty@rustcorp.com.au, jvrao@linux.vnet.ibm.com, qemu-devel@nongnu.org, thuth@de.ibm.com, David Gibson On 11/08/2011 02:39 PM, Aneesh Kumar K.V wrote: > On Tue, 8 Nov 2011 16:55:17 +1100, David Gibson wrote: >> From: Timothy Rule >> >> The 9P spec states that for the stat message the "stat[n]" structure s= hall be >> encoded at offset 7 in the 9P message (see =C2=A713.9 message Rstat). >> >> The existing code is encoding a 2 byte value (hard coded 0 value) at >> offset 7 of the 9P message, and then follows with the "stat[n]" struct= ure >> at offset 9 of the 9P message. >> >> This patch removes the encoding of the 2 byte value which has the effe= ct >> of moving the "stat[n]" structure from offset 9 to offset 7 in the 9P >> message Rstat. >> >> Signed-off-by: Timothy Rule >> Signed-off-by: David Gibson >> --- >> hw/9pfs/virtio-9p.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c >> index 01cf337..35d8851 100644 >> --- a/hw/9pfs/virtio-9p.c >> +++ b/hw/9pfs/virtio-9p.c >> @@ -1279,7 +1279,7 @@ static void v9fs_stat(void *opaque) >> if (err< 0) { >> goto out; >> } >> - offset +=3D pdu_marshal(pdu, offset, "wS", 0,&v9stat); >> + offset +=3D pdu_marshal(pdu, offset, "S",&v9stat); >> err =3D offset; >> trace_v9fs_stat_return(pdu->tag, pdu->id, v9stat.mode, >> v9stat.atime, v9stat.mtime, v9stat.length= ); > The reason for that "w" is explained in the 9p2000 protocol RFC. Toward= s > the end of "wstat" message para we have > > BUGS > > To make the contents of a directory, such as returned by read(5), > easy to parse, each directory entry begins with a size field. For > consistency, the entries in Twstat and Rstat messages also contain > their size, which means the size appears twice. For example, the > Rstat message is formatted as ``(4+1+2+2+n)[4] Rstat tag[2] n[2] > (n-2)[2] type[2] dev[4]...,'' where n is the value returned by > convD2M. > > Also on the client side we do in p9_client_stat > > err =3D p9pdu_readf(req->rc, clnt->proto_version, "wS",&ignored, ret); > if (err) { > > So the above change will break existing client. > > Any reason why you need to make the above change ? > > -aneesh It would be fine for us to implement our solution that way. I apologise=20 for the inconvenience, I wrote this particular function against the=20 9P2000.u specification which does not mention the Bug. Tim.