[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 07 of 10] Transitive grant support
> >>> Steven Smith <steven.smith@xxxxxxxxxx> 05.10.09 13:15 >>> > >Would something like this be acceptable? > >... > >The __attribute__((packed))s are very much not a thing of beauty, but > >it's at least fairly self-contained. > > Hmm, this being a public header, I'm afraid using gcc extensions isn't > appropriate. Okay. How about this one? union grant_entry_v2 { grant_entry_header_t hdr; /* * The frame to which we are granting access. This field has the * same meaning as the grant_entry_v1 field of the same name. */ struct { grant_entry_header_t hdr; uint32_t pad0; uint64_t frame; } full_page; /* * If the grant type is GTF_grant_access and GTF_sub_page is set, * @domid is allowed to access bytes [@page_off,@page_off+@length) * in frame @frame. */ struct { grant_entry_header_t hdr; uint16_t page_off; uint16_t length; uint64_t frame; } sub_page; /* * If the grant is GTF_transitive, @domid is allowed to use the * grant @gref in domain @trans_domid, as if it was the local * domain. Obviously, the transitive access must be compatible * with the original grant. * * The current version of Xen does not allow transitive grants to * be mapped. */ struct { grant_entry_header_t hdr; domid_t trans_domid; uint16_t pad0; grant_ref_t gref; } transitive; uint32_t __spacer[4]; /* Pad to a power of two */ }; Duplicating the header into every field is kind of icky, but I can't see any other way of avoiding unfortunate padding without using gcc extensions. Steven. Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |