* struct blkif_request_segment_aligned
@ 2014-01-31 12:04 Jan Beulich
2014-02-03 9:40 ` Ian Campbell
0 siblings, 1 reply; 5+ messages in thread
From: Jan Beulich @ 2014-01-31 12:04 UTC (permalink / raw)
To: Roger Pau Monne; +Cc: xen-devel
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: struct blkif_request_segment_aligned
2014-01-31 12:04 struct blkif_request_segment_aligned Jan Beulich
@ 2014-02-03 9:40 ` Ian Campbell
2014-02-03 11:36 ` Jan Beulich
0 siblings, 1 reply; 5+ messages in thread
From: Ian Campbell @ 2014-02-03 9:40 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, Roger Pau Monne
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: struct blkif_request_segment_aligned
2014-02-03 9:40 ` Ian Campbell
@ 2014-02-03 11:36 ` Jan Beulich
2014-02-04 8:20 ` Roger Pau Monné
0 siblings, 1 reply; 5+ messages in thread
From: Jan Beulich @ 2014-02-03 11:36 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel, Roger Pau Monne
>>> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: struct blkif_request_segment_aligned
2014-02-03 11:36 ` Jan Beulich
@ 2014-02-04 8:20 ` Roger Pau Monné
2014-02-04 8:25 ` Jan Beulich
0 siblings, 1 reply; 5+ messages in thread
From: Roger Pau Monné @ 2014-02-04 8:20 UTC (permalink / raw)
To: Jan Beulich, Ian Campbell; +Cc: xen-devel
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: struct blkif_request_segment_aligned
2014-02-04 8:20 ` Roger Pau Monné
@ 2014-02-04 8:25 ` Jan Beulich
0 siblings, 0 replies; 5+ messages in thread
From: Jan Beulich @ 2014-02-04 8:25 UTC (permalink / raw)
To: Ian Campbell, Roger Pau Monné; +Cc: xen-devel
>>> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-02-04 8:25 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-01-31 12:04 struct blkif_request_segment_aligned Jan Beulich
2014-02-03 9:40 ` Ian Campbell
2014-02-03 11:36 ` Jan Beulich
2014-02-04 8:20 ` Roger Pau Monné
2014-02-04 8:25 ` Jan Beulich
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.