[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/29/2016 07:05 PM, Jan Beulich wrote:
On 29.11.16 at 17:55, <andr2000@xxxxxxxxx> wrote:
On 11/29/2016 06:09 PM, Jan Beulich wrote:
On 29.11.16 at 16:24, <andr2000@xxxxxxxxx> 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

_______________________________________________
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®.