Re: [Embedded-pv-devel] [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@xxxxxxxxx>]

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

_______________________________________________
Embedded-pv-devel mailing list
Embedded-pv-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/embedded-pv-devel