From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
Subject: Re: struct blkif_request_segment_aligned
Date: Tue, 4 Feb 2014 09:20:06 +0100
Message-ID: <52F0A2B6.4080307@citrix.com>
References: <52EB9F450200007800118618@nat28.tlf.novell.com>
	<1391420407.10515.10.camel@kazak.uk.xensource.com>
	<52EF8D4A0200007800118A67@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1WAbEn-0000OB-VS
	for xen-devel@lists.xenproject.org; Tue, 04 Feb 2014 08:20:10 +0000
In-Reply-To: <52EF8D4A0200007800118A67@nat28.tlf.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>, Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
List-Id: xen-devel@lists.xenproject.org

On 03/02/14 12:36, Jan Beulich wrote:
>>>> On 03.02.14 at 10:40, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> On Fri, 2014-01-31 at 12:04 +0000, Jan Beulich wrote:
>>> Roger,
>>>
>>> so you introduced this, yet looking in a little closer detail I can't seem
>>> to understand why: struct blkif_request_segment is identical in layout,
>>> the sole difference between the two is that in the new structure the
>>> padding field has a name, whereas in the old one it doesn't.
>>
>> Is this something to do with Linux' use of __attribute__((packed)) once
>> again causing confusion? (I really hope not API deviation...)
> 
> Yes, I think it has to do with Linux'es way of defining these
> structures: My assumption is that the embedded (but not such
> attributed) definition of struct blkif_request_segment inside struct
> struct blkif_request_rw was assumed to also be packed (which it
> isn't, or else upstream Linux front-/backends wouldn't work with
> other back-/frontends), thus apparently making it necessary to
> have an "aligned" (i.e. un-packed) variant thereof.

Yes, this is my fault for wrongly assuming struct blkif_request_segment
inside struct blkif_request_rw was also packed, which it is not (or else
it would break with non Linux backends). Thanks for sending the Xen side
patch, I will take care of the Linux side if it's fine with you.

Roger.