>>> 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 >>> 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. > Also, should I remove this: > "All reserved and padding fields in the structures below must be 0." Definitely not. Jan _______________________________________________ Xen-devel mailing list Xenfirstname.lastname@example.org https://lists.xen.org/xen-devel