[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <468A4CDE.5010808@garzik.org>
Date: Tue, 03 Jul 2007 09:19:26 -0400
From: Jeff Garzik <jeff@...zik.org>
To: Inaky Perez-Gonzalez <inaky@...ux.intel.com>
CC: "Kok, Auke" <auke-jan.h.kok@...el.com>,
Michael Buesch <mb@...sch.de>,
Christoph Hellwig <hch@...radead.org>,
Stephen Hemminger <shemminger@...ux-foundation.org>,
"Veeraiyan, Ayyappan" <ayyappan.veeraiyan@...el.com>,
netdev@...r.kernel.org, arjan@...ux.intel.com,
akpm@...ux-foundation.org
Subject: Re: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based
PCI Express adapters...
Inaky Perez-Gonzalez wrote:
> I don't think bitfields are broken. Maybe it's the compiler what should be fixed (*)
Then you do not understand bitfields. It is -axiomatic- that bitfields
are more difficult for compilers to implement.
Access to bitfields are not atomic within the machine int in which they
are stored... you need to "unpack" the values stored in bitfields, even
if they are single-bit bitfields.
You cannot set multiple bitfields at one time, without even more complex
data structures. You cannot compare and test multiple bitfields at one
time.
Humans have proven in kernel-land to screw up bitfields repeatedly.
The evidence is plain to see:
> union {
> struct {
> u32 reserved1:15;
> u32 val:2;
> } __attribute__((packed))
> u32 data;
> } value;
Using "u32 flags", and nothing else, is just so much more simple and
obvious.
Finally, this is -nothing new-. I've been telling other driver writers
not to use bitfields in their drivers. Google for 'garzik' and 'bitfield'.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists