[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.



On 11/30/2016 10:45 AM, Jan Beulich wrote:
On 29.11.16 at 19:44, <andr2000@xxxxxxxxx> wrote:
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?
Yes, I think so.
ok
Also, should I remove this:
"All reserved and padding fields in the structures below must be 0."
Definitely not.
ok
Jan



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.