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.

[Oleksandr Andrushchenko <andr2000@xxxxxxxxx>]

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