On Wednesday 29 April 2009, Sarah Sharp wrote:
> It would be helpful for someone to explain when to use packed and what
> its implications are.
The clearest example of when to use it is to cope
with externally specified data structures, like
message or storage formats (say, USB descriptors),
when either
(a) it's laid out so that C will add undesired
internal padding, or
(b) it won't necessarily meet "natural alignment"
requirements of C.
Your "u32 doorbell[256];" doesn't meet (a), and from
what you wrote I don't think it meets (b) either.
Example:
/* this must use 3 bytes, not 4! */
struct foo {
u8 a;
__le16 b;
} __attribute__((packed));
Not only would C normally add a padding byte after
the "bar", but once you get past that you're also
guaranteed that in "struct foo x[2];" either x[0].b
or x[1].b is unaligned.
Now, if that were "__le16 a" then reason (a) would not
apply. But reason (b) might, if this were embeddable
in some other structure.
When laying out register banks as a structure, it's
conventional to add explicit padding ... though it's
lately become a bit more conventional to use explicit
offsets when addressing, e.g. base + offset_X instead
of ((struct foo *)base)->X style. As a rule, you never
want "packed" annotations there; if the compiler is
inclined to read a 16-bit field as two bytes, that may
well kick in racey hardware behavior.
Similarly when laying out in-memory data structures
that may be accessed by some bus-mastering controller:
use explicit padding. Likewise, you don't want any
"packed" annotations there, although the raciness is
likely going to be harder to trip over.
- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
