Re: [PATCH v14] This is the ABI for the two halves of a para-virtualized sound driver to communicate with each to other.

[Oleksandr Andrushchenko <andr2000@gmail.com>]

On 11/29/2016 08:30 PM, Dario Faggioli wrote:
> On Tue, 2016-11-29 at 19:27 +0200, Oleksandr Andrushchenko wrote:
>> On 11/29/2016 07:05 PM, Jan Beulich wrote:
>>> If you document it as padding, you can't easily use it later on for
>>> some extension.
>> Why not? I would be more careful about reserved, rather than padding.
>> Reserved means that it might be used for something, but padding at
>> the
>> end of the structure (clearly?) says it was added just to align the
>> size of
>> this structure and most probably is not used
>>
> I think that's exactly the point. Padding must be zeroed and can
> (should?) be checked to be zero.
>
> That means that if, say in 2 years time, we want to support a new fancy
> feature being introduced in sound cards, and that requires adding a new
> field in the struct, we can't use these 27 bytes, because we can't set
> them to anything else than a bunch of 0s.
>
> In fact, if you use them in frontend, and happen to speak with a
> backend that does not support the extension and enforces the padding to
> be 0, you're doomed. :-/
>
> OTOH, if you say reserved, neither of the endpoints is authorized to
> assume anything about the content of that area. Therefore:
> 1) you can (with some care) use it for extensions
> 2) if you do that in a frontend, even when speaking with a backend that
> does not support the extension, it will just ignore the new content
> (which is still just reserved space for him), and won't crash the
> communication
>
> Hope this is both correct and clear. :-)
Indeed, it does sound reasonable
Then, should I turn all paddings in all structures into reserved?
Also, should I remove this:
"All reserved and padding fields in the structures below must be 0."
>>>    But you know possible extension routes of this
>>> protocol better than me...
>> Well, after implementing PV sound back and front with this kind of
>> response I can confirm we didn't face any problem.
>> So, I would say it is sufficient
>>
> Eheh, how did it sound? Ah, yes:
> <<640K ought to be enough for anybody.>>
>
> :-D
+1 ;)
> Regards,
> Dario


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