Re: [PATCH] ethtool_ops rev 4

[Jeff Garzik <jgarzik@pobox.com>]

David S. Miller wrote:
> On Fri, 01 Aug 2003 18:35:31 -0400
> Jeff Garzik <jgarzik@pobox.com> wrote:
> 
> 
>>We want to provide a sane, ifdef-free path to kcompat, where feasible.
> 
> 
> I don't believe it's possible with netdev_ops, without
> undoing the entire purpose of what netdev_ops is trying
> to accomplish (elimination of code duplication).
> 
> Show me, in code not words, how you are able to accomplish
> this with SET_NETDEV_OPS() or whatever.  I will not read
> english text describing the scheme, I will read only code :)

Read kcompat.  Then:

#define SET_ETHTOOL_OPS kcompat_set_ethtool_ops

#define DO_ETHTOOL_OPS /* duplicate net/core/ethtool.c, basically */

I would define both of these in Matthew's patch, but one only _needs_ to 
define SET_ETHTOOL_OPS, so I pushed for the latter course.

So why is SET_ETHTOOL_OPS needed?  It covered up the one place

It intentionally follows the same design as SET_MODULE_OWNER, and for 
the same purpose:  hiding what would otherwise be a naked struct deref 
to a struct member that does not exist on an older kernel.

Hiding naked struct derefs is also the reason I created 
pci_{get,drv}_drvdata, pci_resource_*, etc.  Back compat is really a big 
syntactic sugar game, and naked struct derefs are really the only big 
thorn in the side.  Everything else can be beaten down with syntactic 
sugar behind the scenes, that never ever gets merged into the upstream 
kernel.

	Jeff