Re: [Xen-devel] [PATCH 4/5] xen: Add V4V implementation

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.06.12 at 12:03, Jean Guyader <jean.guyader@xxxxxxxxx> wrote:
> On 29 June 2012 09:33, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>> On 28.06.12 at 18:26, Jean Guyader <jean.guyader@xxxxxxxxxx> wrote:
>>> +typedef struct v4v_ring_id
>>> +{
>>> +    struct v4v_addr addr;
>>> +    domid_t partner;
>>> +} V4V_PACKED v4v_ring_id_t;
>>> +
> 
> This structure is really the one that cause trouble. domid_t is 16b
> and v4v_addr_t is used
> inside v4v_ring_t. I would like the structure to remind as close as we
> can from the original version
> as we already versions in the field. Having explicit padding will make
> all the structures different
> which will make much harder to write a driver that will support the
> two versions of the API.

Oh, I see, "partner" would end up on a different offset if the
packed attribute was removed from v4v_addr_t. But that
could still be solved by making this type a union:

typedef union v4v_ring_id
{
    struct v4v_addr addr;
    struct {
        uint32_t port;
        domid_t domain;
        domid_t partner;
    } full;
} v4v_ring_id_t;

That would guarantee binary compatibility. And you could even
achieve source compatibility for gcc users by making the naming
of the second structure conditional upon __GNUC__ being
undefined (or adding a second instance of the same, just
unnamed structure within a respective #ifdef - that would make
it possible to write code that can be compiled by both gcc and
non-gcc, yet existing gcc-only code would need changing).

> Also most all the consumer of those headers will have to rewrite the
> structure anyway, for instance
> the Linux kernel have it's own naming convention, macros definitions
> which are different, etc..

Such can usually be done via scripts, so having a fully defined
public header is still worthwhile.

Jan


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