[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Guidelines for new PV protocol submission

>>> On 20.01.15 at 13:47, <roger.pau@xxxxxxxxxx> wrote:
> I should probably have done this earlier because I've been aware of this
> issue for a long time (since I've started dealing with the PV blk protocol).
> The current way to describe PV protocols in Xen is very inefficient
> IMHO. Using C structs as "the description" of a binary protocol seems
> very wrong, specially taking into account that different ABIs can
> generate different layouts for the same C struct. This is for example a
> problem in the PV blk protocol, since the binary layout of the
> structures change depending on the bitness.
> In order to avoid this, I would like to request that any new PV protocol
> that's added to Xen be described in binary terms, just like it's
> normally done with other protocols. As a reference see for example the
> following section from the TCP RFC:
> http://tools.ietf.org/html/rfc793#page-15 
> I think this is both more easy to understand and removes the bitness
> problem of using C structs.

Since such a layout can be translated to a C struct, I'm having
trouble seeing why not providing C struct-s from the beginning
(and as canonical reference) would be better or more efficient.
The mistake with blkif wasn't that it was written down as a C
struct, but that bitness wasn't taken into account from the

> Then each user of this protocol could define it's own set of structures
> that would map to the binary layout, which should be almost trivial.
> There would be no problem with using __packed or similar gcc'isms as
> each implementation could choose the more convenient way to represent
> this layout internally.

That option exists anyway, and upstream Linux has been doing
so (not to the better imo especially for blkif).


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.