Newsgroups: fa.linux.kernel
From: viro@parcelfarce.linux.theplanet.co.uk
Subject: Re: [PATCH][2.6] IBM PowerPC Virtual Ethernet Driver
Original-Message-ID: <20040218042340.GW8858@parcelfarce.linux.theplanet.co.uk>
Date: Wed, 18 Feb 2004 04:28:46 GMT
Message-ID: <fa.npbcfkt.1tn81qp@ifi.uio.no>

On Wed, Feb 18, 2004 at 04:01:30AM +0000, Dave Jones wrote:
> On Wed, Feb 18, 2004 at 11:45:20AM +1100, Benjamin Herrenschmidt wrote:
>
>  > BITFIELDS ARE EVIL !!!
>  >
>  > Especially when mapping things like HW registers... I know the p/iSeries
>  > code is full of them, I'd strongly recommend getting rid of them.
>  >
>  > The compiler is perfectly free, afaik, to re-order them
>
> That can't be right surely ? That would make them utterly useless afaics.
> I've not seen this happen in practice either with the 2 x86 cpufreq drivers
> I wrote that both use bitfields extensively.

It _is_ right and they are utterly useless.  Original rationale was, indeed,
"describe the layout of hardware registers" but it had gone to hell may years
ago.  Any assumptions regarding their allocation are non-portable.

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: [PATCH][2.6] IBM PowerPC Virtual Ethernet Driver
Original-Message-ID: <Pine.LNX.4.58.0402172044321.2686@home.osdl.org>
Date: Wed, 18 Feb 2004 04:48:57 GMT
Message-ID: <fa.j4s4rtf.1cicmop@ifi.uio.no>

On Wed, 18 Feb 2004 viro@parcelfarce.linux.theplanet.co.uk wrote:
> >
> > That can't be right surely ? That would make them utterly useless afaics.
> > I've not seen this happen in practice either with the 2 x86 cpufreq drivers
> > I wrote that both use bitfields extensively.
>
> It _is_ right and they are utterly useless.  Original rationale was, indeed,
> "describe the layout of hardware registers" but it had gone to hell may years
> ago.  Any assumptions regarding their allocation are non-portable.

Well, to be fair, most compilers still aim to make them useful.

There's a difference between "the standard doesn't guarantee anything" and
"the implementation makes no sense".

(Sadly, a lot of compiler people do seem to look to standards more than
actual users for guides to do things, but at the same time I do believe
that gcc has useful semantics for bitfields and hardware accesses. You
just have to know what the implementation-specific rules are)

		Linus

Newsgroups: fa.linux.kernel
From: viro@parcelfarce.linux.theplanet.co.uk
Subject: Re: [PATCH][2.6] IBM PowerPC Virtual Ethernet Driver
Original-Message-ID: <20040218050457.GZ8858@parcelfarce.linux.theplanet.co.uk>
Date: Wed, 18 Feb 2004 05:11:29 GMT
Message-ID: <fa.nrbsf4u.1rn41au@ifi.uio.no>

On Tue, Feb 17, 2004 at 08:46:52PM -0800, Linus Torvalds wrote:
> > ago.  Any assumptions regarding their allocation are non-portable.
>
> Well, to be fair, most compilers still aim to make them useful.
>
> There's a difference between "the standard doesn't guarantee anything" and
> "the implementation makes no sense".
>
> (Sadly, a lot of compiler people do seem to look to standards more than
> actual users for guides to do things, but at the same time I do believe
> that gcc has useful semantics for bitfields and hardware accesses. You
> just have to know what the implementation-specific rules are)

True.  However, most of the bitfield uses I've seen would become much cleaner
from rewrite to explicit mask-and-shift stuff.

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: [PATCH][2.6] IBM PowerPC Virtual Ethernet Driver
Original-Message-ID: <Pine.LNX.4.58.0402180834460.2686@home.osdl.org>
Date: Wed, 18 Feb 2004 16:42:08 GMT
Message-ID: <fa.j4csrdg.1e2kn8m@ifi.uio.no>

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.

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: [PATCH 1/2] BDI: Provide backing device capability information
Original-Message-ID: <Pine.LNX.4.58.0503021423420.25732@ppc970.osdl.org>
Date: Wed, 2 Mar 2005 22:45:32 GMT
Message-ID: <fa.isndn02.14k0brm@ifi.uio.no>

On Wed, 2 Mar 2005, Andrew Morton wrote:
>
> Why not make these bitfields as well?

Side note: bitfields aren't exactly wonderful. They tend to generate worse
code, and they make it much harder to work with combinations of flags
(both testing and initializing). They also have architecture-specific
bit-order and packing issues, which means that when coupled with device
drivers etc they can be a major pain in the derriere.

Even apart from those issues, they can't sanely be atomically accessed, so
in many cases they just aren't a good thing.

In contrast, just using a flag word and explicit bitmask has none of those
problems, and it's often easy to abstract out things with a macro and/or
inline function.

So don't go for bitfields "just because". It's generally a good idea to
_require_ that the code in question has none of the potential problem
spots even in _theory_, and in addition also show that bitfields really
make the code look nicer. The downsides really can be that nasty.

		Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: [patch] Add helper macros for little-endian bitfields
Date: Wed, 27 Aug 2008 21:27:34 UTC
Message-ID: <fa.02EUSOP/ekfiSdhLw3OvF4opWP4@ifi.uio.no>

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