Michael Wu wrote:
On Saturday 15 September 2007 20:56, Jeff Garzik wrote:
+ if (flags & IFF_PROMISC)
+ dev->flags |= IEEE80211_HW_RX_INCLUDES_FCS;
+ else
+ dev->flags &= ~IEEE80211_HW_RX_INCLUDES_FCS;
why does promisc dictate inclusion of FCS?
Because that's the way the hardware works.
Why not always include it, regardless of promisc?
I really do mean that's how the hardware works. If you turn on the promisc bit
in the hardware (which IFF_PROMISC causes), it starts including the FCS, but
if the bit is not set, the FCS is not included in frames.
OK, I was confused by the name. Based on the constant's name, I was
assuming that you could unconditionally enable it, promisc or not.
Nevermind. I thought that was a hardware rather than software bit.
What form of debugging are you talking about? I don't see how it makes a
difference for debugging. The type checking provided by enums won't make a
When you are tracing through with kgdb, the code is actually readable.
You see
dev->flags |= IEEE80211_HW_RX_INCLUDES_FCS;
rather than the far more obtuse
dev->flags |= 8;
Ditto for any time you have to read pre-processed source code. I do so
at least once a month, since post-cpp code shows you precisely what the
compiler is munching, after all the macro magic goes away.
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
