[Top] [All Lists]

Re: [PATCH] ethtool_ops rev 4

To: "David S. Miller" <davem@xxxxxxxxxx>
Subject: Re: [PATCH] ethtool_ops rev 4
From: Jeff Garzik <jgarzik@xxxxxxxxx>
Date: Fri, 01 Aug 2003 19:09:35 -0400
Cc: willy@xxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <>
Organization: none
References: <> <> <> <> <> <> <> <>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk
David S. Miller wrote:
On Fri, 01 Aug 2003 18:35:31 -0400
Jeff Garzik <jgarzik@xxxxxxxxx> 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.


<Prev in Thread] Current Thread [Next in Thread>