From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KQ78M-0007m1-Uu for qemu-devel@nongnu.org; Mon, 04 Aug 2008 16:58:27 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KQ78L-0007iw-1g for qemu-devel@nongnu.org; Mon, 04 Aug 2008 16:58:26 -0400 Received: from [199.232.76.173] (port=38259 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KQ78K-0007it-VB for qemu-devel@nongnu.org; Mon, 04 Aug 2008 16:58:24 -0400 Received: from py-out-1112.google.com ([64.233.166.181]:52269) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KQ78K-0005jD-NB for qemu-devel@nongnu.org; Mon, 04 Aug 2008 16:58:24 -0400 Received: by py-out-1112.google.com with SMTP id p76so1178663pyb.10 for ; Mon, 04 Aug 2008 13:58:24 -0700 (PDT) Message-ID: Date: Mon, 4 Aug 2008 23:58:23 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] [PATCH 5/7] xen: add block device backend driver. In-Reply-To: <48975D9A.7070109@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1217865045-10722-1-git-send-email-kraxel@redhat.com> <1217865045-10722-6-git-send-email-kraxel@redhat.com> <48975D9A.7070109@redhat.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org On 8/4/08, Gerd Hoffmann wrote: > Blue Swirl wrote: > > On 8/4/08, Gerd Hoffmann wrote: > >> +/* i386 protocol version */ > >> +#pragma pack(push, 4) > > > > What's wrong with __attribute__(__aligned__)? > > > That one is tricky because we must be binary compatible with xen. And > the block driver protocol has a small design flaw: It has a 64bit value > which is not aligned on a 64bit border. This leads to different struct > layouts on i386 and x86_64 due to different alignment rules. Unless you > force them into something else, like we do in that header file to deal > with it. Which is needed to run 32bit guests on 64bit hosts. Isn't this internal Xen protocol, so hopefully next version of Xen could use more efficient structures? > > Would I need to add > > Sparc32 and Sparc64 versions some day? > > > Not sure whenever the same 32/64bit ABI issue exists on sparc. If so, > the code handling this on x86 should work for sparc too. Well, I'd rather define a new, more architecturally neutral structure.