[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC 12/12] xen-block: implement indirect descriptors
>>> On 28.02.13 at 11:28, Roger Pau Monne <roger.pau@xxxxxxxxxx> wrote: > @@ -109,6 +111,16 @@ typedef uint64_t blkif_sector_t; > */ > #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11 > > +#define BLKIF_MAX_INDIRECT_GREFS_PER_REQUEST 8 > + > +struct blkif_request_segment_aligned { > + grant_ref_t gref; /* reference to I/O buffer frame */ > + /* @first_sect: first sector in frame to transfer (inclusive). */ > + /* @last_sect: last sector in frame to transfer (inclusive). */ > + uint8_t first_sect, last_sect; > + uint16_t _pad; /* padding to make it 8 bytes, so it's cache-aligned > */ > +} __attribute__((__packed__)); What's the __packed__ for here? > + > struct blkif_request_rw { > uint8_t nr_segments; /* number of segments */ > blkif_vdev_t handle; /* only for read/write requests */ > @@ -138,11 +150,24 @@ struct blkif_request_discard { > uint8_t _pad3; > } __attribute__((__packed__)); > > +struct blkif_request_indirect { > + uint8_t indirect_op; > + uint16_t nr_segments; > +#ifdef CONFIG_X86_64 > + uint32_t _pad1; /* offsetof(blkif_...,u.indirect.id) == 8 > */ > +#endif Either you want the structure be packed tightly (and you don't care about misaligned fields), in which case you shouldn't need a padding field. That's even more so as there's no padding between indirect_op and nr_segments, so everything is misaligned anyway, and the comment above is wrong too (offsetof() really ought to yield 7 in that case). Or you want the structure fields aligned, in which case you again ought to drop the use of the __packed__ attribute and introduce _all_ necessary padding fields. > + uint64_t id; > + blkif_vdev_t handle; > + blkif_sector_t sector_number; > + grant_ref_t indirect_grefs[BLKIF_MAX_INDIRECT_GREFS_PER_REQUEST]; > +} __attribute__((__packed__)); And then it would be quite nice for new features to no longer require translation between a 32- and a 64-bit layout at all. Plus, rather than introducing uninitialized padding fields, I'd suggest using fields that are required to be zero initialized, to allow giving them a meaning later. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |