struct blkif_request_segment_aligned

struct blkif_request_segment_aligned

[Jan Beulich]

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.

I'd really like to get rid of this redundant type again, unless there's a
reason for it to be there which I'm overlooking.

Jan

Re: struct blkif_request_segment_aligned

[Ian Campbell]

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...)

> I'd really like to get rid of this redundant type again, unless there's a
> reason for it to be there which I'm overlooking.
> 
> Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: struct blkif_request_segment_aligned

[Jan Beulich]

>>> 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.

Jan

>> I'd really like to get rid of this redundant type again, unless there's a
>> reason for it to be there which I'm overlooking.
>> 
>> Jan
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org 
>> http://lists.xen.org/xen-devel 

Re: struct blkif_request_segment_aligned

[Roger Pau Monné]

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.

Re: struct blkif_request_segment_aligned

[Jan Beulich]

>>> On 04.02.14 at 09:20, Roger Pau Monné<roger.pau@citrix.com> wrote:
> 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.

Please do.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel