Date: Wed, 27 Aug 2008 14:26:35 -0700 (PDT)
From: Linus Torvalds <torvalds@linux-foundation.org>
To: David Vrabel <david.vrabel@csr.com>
cc: Al Viro <viro@ZenIV.linux.org.uk>, Roland Dreier <rdreier@cisco.com>,
       Kernel development list <linux-kernel@vger.kernel.org>,
       linux-usb <linux-usb@vger.kernel.org>
Subject: Re: [patch] Add helper macros for little-endian bitfields
In-Reply-To: <48B570D6.7070301@csr.com>
Message-ID: <alpine.LFD.1.10.0808271424030.3363@nehalem.linux-foundation.org>
References: <48AD6AF0.3050504@csr.com> <48AD6B93.7020702@csr.com> <adaprnxnac8.fsf@cisco.com> <20080825014311.GS28946@ZenIV.linux.org.uk> <48B570D6.7070301@csr.com>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1107
Lines: 29


On Wed, 27 Aug 2008, David Vrabel wrote:
> 
> But why is this worthy of a crispy flaming?  I've not seen anything
> definite beyond a somewhat vague 'some compilers don't optimize
> bitfields very well'.

Actually, it's not that compilers often optimize bitfields really badly.

It's also that bitfields are a total f*cking disaster when it comes to 
endianness. As you found out.

Bitfields are fine if you don't actually care about the underlying format, 
and want gcc to just randomly assign bits, and want things to be 
convenient in that situation.

But _if_ you care about the underlying format, then inevitably the 
bitfield costs will be much higher than just using bit operations on a
"u32" or similar. Your helper macros are horrible compared to just making 
the bits work out right to begin with, and using the standard byte order 
things.

		Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/