Dear Mike Frysinger,
In message 201111111003.15436.vapier@gentoo.org you wrote:
I'm OK with expanding the name[] field, but as Thomas pointed out, providing "convenient" u32 / u16 variables for the MAC address is actually a faux ami that misleads people into using these variables without thinking about endianess and such.
Please omit this part.
there's always the endian issue. i'd wager that the vast majority of the time, the endian of the target hardware is the same as the core. so omitting this for odd devices or device driver writers who aren't careful is being too pessimistic imo. i can add qualifiers to the name like "enetaddr_cpu32" if you
No. Please drop this.
want. looking at the generated code shows really nice improvements: a single cpu load instead of 4 loads interspersed with bitshifts.
This is neither memory nor performance critical, but it is easy to misuse and thus dangerous.
Best regards,
Wolfgang Denk