On 11/30/2016 10:45 AM, Jan Beulich wrote:
On 29.11.16 at 19:44, <andr2...@gmail.com> 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
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

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.
Also, should I remove this:
"All reserved and padding fields in the structures below must be 0."
Definitely not.

Xen-devel mailing list

Reply via email to