Re: [Xen-devel] [PATCH v4 03/11] public: xen.h: add definitions for UUID handling

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 30.08.17 at 18:20, <volodymyr_babchuk@xxxxxxxx> wrote:
> My first intention was to declare union with all possible 
> representations, so it would be possible to access the same UUID as an 
> array of bytes or, for example, as Microsoft GUID. Like this:
> 
> typedef union {
>      /* UUID represented as a 128-bit object */
>      uint8_t obj[16];
> 
>      /* Representation according to RFC 4122 */
>      struct {
>          __be32  time_low;
>          __be16  time_mid;
>          __be16  time_hi_and_version;
>          __u8    clock_seq_hi_and_reserved;
>          __u8    clock_seq_low;
>          __u8    node[6];
>      } rfc4122;
> 
>      /* Microsoft/Intel style GUID representation */
>      struct {
>          __le32  Data1;
>          __le16  Data2;
>          __le16  Data3;
>          __u8    Data4[8];
>      } guid;
> 
>      /* SMCCC compatible format */
>      struct {
>          __le32 r0;
>          __le32 r1;
>          __le32 r2;
>          __le32 r3;
>      } smccc;
> } xen_uuid_t;
> 
> 
> But looks like we can't use something like __packed or 
> __attribute__((__packed__)) in the public header. This means that we 
> can't rely on right overlapping and users of this union should take care 
> to read and write only to one chosen substructure.

I don't see any use of that attribute in the structure definition
above, nor any need to add one - all fields are suitably aligned
anyway. You can't use __be* and __le* types in the public
headers, though - these will need to be uint*_t.

> BTW, I'm very interested how it can be guaranteed that structures 
> defined in xen.h will have the same size and alignment on both sides of 
> communication channel, taking into account, then we rely only on C89 
> standard.

I don't understand this comment.

Jan


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