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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
