[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Embedded-pv-devel] [PATCH v10] xen: add para-virtual sound interface header file
- To: Jan Beulich <JBeulich@xxxxxxxx>
- From: Oleksandr Andrushchenko <andr2000@xxxxxxxxx>
- Date: Fri, 25 Nov 2016 09:41:20 +0200
- Cc: Lars Kurth <lars.kurth@xxxxxxxxxx>, Iurii Konovalenko <iurii.konovalenko@xxxxxxxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Volodymyr Babchuk <vlad.babchuk@xxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, Dario Faggioli <dario.faggioli@xxxxxxxxxx>, ian.jackson@xxxxxxxxxxxxx, al1img@xxxxxxxxx, Andrii Anisov <andrii.anisov@xxxxxxxxx>, Oleksandr Tyshchenko <olekstysh@xxxxxxxxx>, embedded-pv-devel <embedded-pv-devel@xxxxxxxxxxxxxxxxxxxx>, Julien Grall <julien.grall@xxxxxxx>, David Vrabel <david.vrabel@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Oleksandr Dmytryshyn <oleksandr.dmytryshyn@xxxxxxxxxxxxxxx>, Mygaiev Artem <joculator@xxxxxxxxx>
- Delivery-date: Fri, 25 Nov 2016 07:41:25 +0000
- List-id: <embedded-pv-devel.lists.xenproject.org>
On 11/25/2016 09:11 AM, Jan Beulich wrote:
On 24.11.16 at 18:11, <andr2000@xxxxxxxxx> wrote:
+struct xensnd_close_req {
+};
I'm afraid structures without any members aren't permitted by C89.
There are 2 options I see:
1. Remove empty structures
2. Leave them in, but add a comment and add a dummy place holder
I would prefer option 1 as this way the interface seems to be clearer,
like all requests are defined etc.
I'm not really sure which option is better, so I'd leave this to the
(soon to be sole) maintainer of those files (Konrad - I don't think
I've seen v2 of that patch yet).
I am preparing a new patch now, will publish soon
+struct xensnd_request {
+ uint8_t raw[64];
+};
+
+struct xensnd_response {
+ uint8_t raw[64];
+};
What are these two needed for now? If you want to enforce a
minimum size, that would better go ...
That is because we want to be cache line aligned. What it means in practice
is not clear as we have so many HW around, so it is not possible to
fit all. So the options could be:
1. 32 or 64
2. 48 I think is not an option here
I would stick to 32
I don't understand why you switched over to discussing size, when all
I've asked for is to change the placement of these size enforcing
constructs (after all by themselves they're not useful types).
You are absolutely right, will fix
Jan
_______________________________________________
Embedded-pv-devel mailing list
Embedded-pv-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/embedded-pv-devel
|