On 11/29/2016 07:05 PM, Jan Beulich wrote:
On 29.11.16 at 17:55, <andr2...@gmail.com> wrote:
On 11/29/2016 06:09 PM, Jan Beulich wrote:
On 29.11.16 at 16:24, <andr2...@gmail.com> wrote:
+struct xensnd_req {
+ uint16_t id;
+ uint8_t operation;
+ uint8_t stream_idx;
+ uint32_t reserved;
+ union {
+ struct xensnd_open_req open;
+ struct xensnd_rw_req rw;
+ uint8_t padding[24];
+ } op;
+};
+
+struct xensnd_resp {
+ uint16_t id;
+ uint8_t operation;
+ uint8_t stream_idx;
+ int8_t status;
+ uint8_t padding[27];
Other than in _req, this ought to be "reserved" imo.
IMO, this is a classic padding, why reserved?
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
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
Jan
Thank you,
Oleksandr
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
