Dealing with M_HASFCS for protocols that do not do ethernet crc

[Martin Husemann <martin%duskware.de@localhost>]

Hey folks,

we recently saw a fix (for dev/ic/dwc_gmac.c) to one of the (10?) drivers
that blindly set M_HASFCS on mbufs because their hardware does not strip
the ethernet crc off automatically.

The log message explains the issue well:

------------------------------------------------------------------------
Do not unilaterally set M_HASFCS; this breaks protocols that lack CRC bytes
(such as AppleTalk).

Instead, remove/preserve the final four bytes in the packet ourselves on a per-
protocol basis, as we do in arch/arm/xscale/ixp425_if_npe.c (and dev/ic/gem.c,
and so forth).
------------------------------------------------------------------------

My problem with this change is:

 - it only happened to a single affected driver (probably as testing all the
   others was impossible)
 - none of the drivers pointed at as examples for stripping the bytes off
   "manually" has any special code for ATALK or AARP (like this change
   introduced for dwc_gmac.c)

So I wonder if we should redefine the meaning of M_HASFCS from "FCS included
at the end of frame" to "Frame may have FCS included at the end if protocol
uses a FCS", and then have if_ethersubr.c deal with it generically.

But I probably am overlooking tons of corner cases.

Do most drivers just not care about it because their hardware always strips
off the crc?

Maybe the drivers that just always set M_HASFCS need to check for a
receive ring/buffer flag that tells them about the crc instead?

Martin