Jeff Garzik wrote:
Arjan van de Ven wrote:
Jeff Garzik wrote:
always avoid bitfields. They generate horrible code, and endian
problems abound (though no endian problems are apparent here).
they generate no worse code than open coding the checks for these
feature flags...
That would be the logical assumption, but reality does not bear that
logic out to be true.
I just checked a small example and gcc just generates a testb with an
immediate value, which isn't all that bad code.
Do you remember which gcc you tested with?
gcc 2.95, gcc 3.x, gcc 4.x, ... on multiple architectures, not just ia32.
It's simple logic: using machine integers are the easiest for the
compiler to Do The Right Thing, the easiest way to eliminate endian
problems, the easiest way for programmers to read and understand struct
alignment.
I really disagree with you here, I much rather prefer using code style like:
if (adapter->flags.msi_enabled) ..
than
if (adapter->flags & E1000_FLAG_MSI_ENABLED) ...
not only does it read easier, it's also shorter and not prone to &/&& confusion
typo's, takes away parentheses when the test has multiple parts etc...
Maybe this is not most important for ixgbe, where we only have 8 or so flags,
but the new e1000 driver that I posted this weekend currently has 63 (you wanted
flags ;)) of them. Do you want me to use 63 integers or just 2 ?
And as Arjan said, we're not passing any of these to hardware, so there should
not be any endian issues.
I think acme would agree with me that pahole currently is the easiest way to
show struct alignment ...
Auke
-
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
