Donald Becker wrote:
> Removing the code prevents backward compatibility, and risks a similar
> change in the future either breaking drivers, or perhap worse, silently
> having a very bad performance impact that is difficult to trace to the
> source.
Removing the code does NOT prevent backward compatibility, as you and
Jes claim.
It is trivial to do something like the following for older kernels:
#define init_etherdev compat_init_etherdev
static inline compat_init_etherdev(...) {...}
Then you would need a corresponding kfree_etherdev() to kfree 'dev' on
newer kernels, OR 'dev' and 'dev->priv' on older kernels.
> The bad performance comes when a chip has to do three or more PCI
> transactions instead of one to transfer data. An over-by-one alignment can
> cause more than one extra transactions, since many chips recover from
> misalignment by ramping up transfer lengths by powers of two until they are
> back on a cache line boundary. (You might claim the hardware should be
> smarter, but it's the software people that shouldn't make the mistake.)
>
> You should understand why the code exists before changing it.
You should open your mind before claiming backward compat is impossible
:)
--
Jeff Garzik | My to-do list is a function
Building 1024 | which approaches infinity.
MandrakeSoft, Inc. |
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
