Jörn Engel wrote:
> On Sun, 9 November 2008 16:52:36 +0200, Boaz Harrosh wrote:
>> +struct osdv1_cdb {
>> + struct osd_cdb_head h;
>> + u8 caps[OSDv1_CAP_LEN];
>> + struct osd_security_parameters sec_params;
>> +} __packed;
>
> __packed can result in slow code being generated. But removing the
> attribute can lead to bugs on other architectures. F.e. the size of
> the structure below is different for i386 and x86_64.
>
> struct foo {
> u64 bar;
> u32 baz;
> };
>
> My personal solution is to use this little macro and then just follow
> every structure defition with a size check.
>
> #define SIZE_CHECK(type, size) \
> static inline void check_##type(void) \
> { \
> BUILD_BUG_ON(sizeof(struct type) != (size)); \
> }
> ...
> struct foo {
> u64 bar;
> u32 baz;
> };
>
> SIZE_CHECK(foo, 12);
>
> The above would not compile on x86_64 and clearly indicate a missing
> __packed. In other cases the attribute can be removed.
>
> Jörn
>
Hi Jörn
Thank you for your comments
I do have a size check that governs the complete structure it is the first
code in osd_initiator.c at build_test(). It will catch any discrepancies
from the protocol.
I have done some experimentation with __packed both on 32 and 64 bit x86.
When it does nothing like the above foo in 32bit, then there is no code
difference with it or with out it, but on 64bit I must have it otherwise
the structure grows.
These are all, on-the-wire structures. I must have __packed, otherwise
I'm at the compiler mercy and that's bad.
If the assembly - size and offsets - of foo is exactly the same with or
without the __packed, but the generated code is different then clearly this
is a compiler bug. I've herd of this myth before, and at least with my
gcc 4.1.2 there is no such bug. Either the structure gets packed, or there is
no difference. All the places I have __packed in the code are absolutely must
be so, stated by the protocol.
Boaz
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
