Re: [Xen-devel] [DRAFT v2] XenSock protocol design document

[Juergen Gross <jgross@xxxxxxxx>]

On 20/07/16 00:38, Stefano Stabellini wrote:
> On Fri, 15 Jul 2016, Paul Durrant wrote:
>>> -----Original Message-----
>>> From: Juergen Gross [mailto:jgross@xxxxxxxx]
>>> Sent: 15 July 2016 12:37
>>> To: Stefano Stabellini; xen-devel@xxxxxxxxxxxxxxxxxxxx
>>> Cc: joao.m.martins@xxxxxxxxxx; Wei Liu; Roger Pau Monne; Lars Kurth;
>>> boris.ostrovsky@xxxxxxxxxx; Paul Durrant
>>> Subject: Re: [DRAFT v2] XenSock protocol design document
>>>
>>> On 13/07/16 17:47, Stefano Stabellini wrote:
>>>> Hi all,
>>>>
>>>> This is the design document of the XenSock protocol. You can find
>>>> prototypes of the Linux frontend and backend drivers here:
>>> ...
>>>> ### Commands Ring
>>>>
>>>> The shared ring is used by the frontend to forward socket API calls to the
>>>> backend. I'll refer to this ring as **commands ring** to distinguish it 
>>>> from
>>>> other rings which will be created later in the lifecycle of the protocol 
>>>> (data
>>>> rings). The ring format is defined using the familiar `DEFINE_RING_TYPES`
>>> macro
>>>> (`xen/include/public/io/ring.h`). Frontend requests are allocated on the
>>> ring
>>>> using the `RING_GET_REQUEST` macro.
>>>>
>>>> The format is defined as follows:
>>>>
>>>>     #define XENSOCK_SOCKET         0
>>>>     #define XENSOCK_CONNECT        1
>>>>     #define XENSOCK_RELEASE        2
>>>>     #define XENSOCK_BIND           3
>>>>     #define XENSOCK_LISTEN         4
>>>>     #define XENSOCK_ACCEPT         5
>>>>     #define XENSOCK_POLL           6
>>>>
>>>>     struct xen_xensock_request {
>>>>            uint32_t id; /* private to guest, echoed in response */
>>>>            uint32_t cmd; /* command to execute */
>>>>            uint64_t sockid;
>>>>            union {
>>>>                    struct xen_xensock_socket {
>>>>                            uint32_t domain;
>>>>                            uint32_t type;
>>>>                            uint32_t protocol;
>>>>                    } socket;
>>>>                    struct xen_xensock_connect {
>>>>                            uint8_t addr[28];
>>>>                            uint32_t len;
>>>>                            uint32_t flags;
>>>>                            grant_ref_t ref;
>>>>                            uint32_t evtchn;
>>>>                    } connect;
>>>>                    struct xen_xensock_bind {
>>>>                            uint8_t addr[28];
>>>>                            uint32_t len;
>>>>                    } bind;
>>>>                    struct xen_xensock_listen {
>>>>                            uint32_t backlog;
>>>>                    } listen;
>>>>                    struct xen_xensock_accept {
>>>>                            uint64_t sockid;
>>>>                            grant_ref_t ref;
>>>>                            uint32_t evtchn;
>>>>                    } accept;
>>>>            } u;
>>>>     };
>>>
>>> Please add padding at the end (or a dummy union member) to make sure
>>> 32- and 64-bit variants have the same size (I believe now the size will
>>> be 60 bytes on 32-bit system and 64 bytes on 64-bit).
> 
> Well spotted! You have a point, I think you are right, even though it
> makes the struct a bit awkward.

Why awkward? just add a "uint8_t dummy[48];" to u.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel