On 27 April 2013 11:53, Oleksij Rempel <linux@xxxxxxxxxxxxxxxx> wrote: >> (And then go and re-align things inside that struct so you don't waste >> space.) > > > hmm.. what do you mean here? Structure alignment? Well, you typically want to have everything be dword aligned (32 bits) or word (16 bits) aligned. Otherwise the compiler may insert extra padding between fields in order to meet alignment requirements on platforms that need it (MIPS, older ARM) or platforms that perform slower (newer ARM.) Eg: u32 a; u16 b; u8 c; u8 d; .. that's fine - the u32 is dword aligned, the u16 is word aligned, the u8's don't need aligning. But, considder: u32 a; u8 b; u16 c; u8 d; .. u32 is dword aligned, u8 b is fine as it's a a byte and doesn't need aligning, but 'u16 c' isn't dword aligned! So the compiler will insert a byte padding between 'b' and 'c'. same deal with: u32 a; u16 b; u32 c; .. 'a' is fine; 'b' is fine, but 'c' starts at a word boundary, not a dword boundary. Hence why things like IP/TCP headers and such look the way they do. :-) Now, i don't know what 'bool' is, whether it's a byte, word or dword. That "is_mybeacon" field should probably be just another flag in rx_status, then just extend 'rs_flags' to 16 bits and include it. That way the alignment is easy to see - all the fields in rx_status and the htc rx_status structs have explicit sizes. :-) Felix, what do you think? Adrian -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
