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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----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).
> 

Actually, rather than this bunch of structs that assume a System V ABI, maybe 
we need a spec. more along the lines of the (ancient) TPI doc. 
http://pubs.opengroup.org/onlinepubs/009618999/toc.htm. After all, like TPI, 
this is a message passing protocol.

  Paul

> 
> Juergen


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