Hi Ed, I have faced issues while making my driver host endian independent. Big Endianness: Stores most significant byte at the least byte address. Little Endianness: Opposite of above. Now when we come to the case of bit fields things change a bit. Bit order usually follow the byte endianess - so the least significant bit is at the smallest address of bits. The network order however is big endian, so if you see the linux/tcp.h some of the fields would be: - #if defined(__LITTLE_ENDIAN_BITFIELD) __u16 res1:4, doff:4, fin:1, syn:1, rst:1, psh:1, ack:1, urg:1, res2:2; #elif defined(__BIG_ENDIAN_BITFIELD) __u16 doff:4, res1:4, res2:2, urg:1, ack:1, psh:1, rst:1, syn:1, fin:1; #else #error "Adjust your <asm/byteorder.h> defines" #endif This way you can access the fields directly using Arrow operator "->". Thanks, Vishwas -----Original Message----- From: kernelnewbies-bounce@nl.linux.org [mailto:kernelnewbies-bounce@nl.linux.org]On Behalf Of Ed L Cashin Sent: Friday, February 20, 2004 11:38 PM To: kernelnewbies@nl.linux.org Subject: bit-endian-ness (was Re: [PATCH][2.6] IBM PowerPC Virtual Ethernet Driver) On the lkml, I saw this post: Linus Torvalds <torvalds@osdl.org> writes: > On Wed, 18 Feb 2004, Benjamin Herrenschmidt wrote: >> >> Well... I still think it's asking for trouble in the long term >> to rely on them .... It's definitely broken for drivers of devices >> that can be used on different archs (PCI cards for example) since >> the layout of the bitfields is different at least with gcc between >> big and little endian machines. But I've also been bitten by >> alignement issues within the bitfield in the past (not with gcc >> though) and other funny things like that... > > I mostly agree. > > You _can_ get bitfields correct, but it takes some care. And btw, bit > endianness within a word does not necessarily match the byte endianness, > although they are usually connected. > > See for example <linux/tcp.h> for what you need to do to make bitfields > work right across architectures. > >> So overall, I just recommend to get rid of them. > > In general, yes. You can make bitfields be more readable, but you need to > be careful. And we all know how careful most driver writers tend to be. It's an interesting thread about bitfields. Does anyone know about the bit-endianness issue that Linus mentions? What implications does this issue have for kernel programming? ____________________________________________________________ Find what you are looking for with the Lycos Yellow Pages http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10 -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
