Re: [Xen-devel] [PATCH DOCDAY v2] netif.h: describe request/response structures in terms of binary layout

2015-03-03 Thread Ian Campbell
On Wed, 2015-02-25 at 13:39 +, Ian Campbell wrote: > In RFC style, rather than relying on the implicit assumptions of a > particular C ABI. > > I have also confirmed, using the Python gdb extension technique in > [0], that the struct offsets (in a Linux binary at least) are the same > as descr

Re: [Xen-devel] [PATCH DOCDAY v2] netif.h: describe request/response structures in terms of binary layout

2015-03-02 Thread David Vrabel
On 02/03/15 17:08, Ian Campbell wrote: > On Wed, 2015-02-25 at 13:57 +, David Vrabel wrote: >> On 25/02/15 13:39, Ian Campbell wrote: >>> >>> + * Guest transmit >>> + * == >>> + * >>> + * Ring slot size is 12 octets, however not all request/response >>> + * structs use the full size

Re: [Xen-devel] [PATCH DOCDAY v2] netif.h: describe request/response structures in terms of binary layout

2015-03-02 Thread Ian Campbell
On Wed, 2015-02-25 at 13:57 +, David Vrabel wrote: > On 25/02/15 13:39, Ian Campbell wrote: > > > > + * Guest transmit > > + * == > > + * > > + * Ring slot size is 12 octets, however not all request/response > > + * structs use the full size. > > + * > > + * tx request data (netif_

Re: [Xen-devel] [PATCH DOCDAY v2] netif.h: describe request/response structures in terms of binary layout

2015-02-25 Thread David Vrabel
On 25/02/15 13:39, Ian Campbell wrote: > > + * Guest transmit > + * == > + * > + * Ring slot size is 12 octets, however not all request/response > + * structs use the full size. > + * > + * tx request data (netif_tx_request_t) > + * > + * > + *0

[Xen-devel] [PATCH DOCDAY v2] netif.h: describe request/response structures in terms of binary layout

2015-02-25 Thread Ian Campbell
In RFC style, rather than relying on the implicit assumptions of a particular C ABI. I have also confirmed, using the Python gdb extension technique in [0], that the struct offsets (in a Linux binary at least) are the same as described here. I took the opportunity to also confirm that x86_32, x86