On Saturday 03 November 2012 15:22:26 David Miller wrote: [...] > Your packet layouts are very poorly designed and I want you to stop > and think seriously about things before extending things further.
You are right about the packet design/layout. But I also have some problems
with the following statement. Maybe you can help me to resolve it.
> All of this __packed stuff is a serious problem.
>
> It means that on RISC system, fields such as your 32-bit sequence
> number, will be read and written using byte loads and stores.
>
> This is terrible.
>
> Instead, design the structures so that they are full filled out to
> at least 4 byte boundaries, so that they and the contents after
> them, are 4 byte aligned too.
>
> Then you won't need to mark all of your packet header structs
> with __packed, and therefore the compiler can use full 32-bit
> loads and stores to access 32-bit fields.
Ok, lets assume batman-adv has everything 4 byte aligned and we are running on
a machine without unaligned r/w access. The machine may issues bus errors and
so on.
Now also assume following really unusual situation: We get our data from a
ethernet driver and the skb stores the ethernet header. The start of the
ethernet header is perfectly aligned (4 or even 16 byte boundary aligned). The
the header is 14/18 byte long (6 byte src, 6 byte dst, 2 byte ethertype and
maybe 4 byte vlan). Now the payload starts only on a 2 byte boundary -> it is
never 4 byte boundary aligned. A 32 bit read now causes different variations
of problems (reminder: bus error).
This brings me to the question: Why should the "32 bit align everything
relative to the start of the struct" approach help to resolve the situation
for the access of 32 bit data structure members? May I am missing some
information?
Kind regards,
Sven
signature.asc
Description: This is a digitally signed message part.
