David S. Miller wrote:
On Fri, 01 Aug 2003 19:09:35 -0400
Jeff Garzik <jgarzik@xxxxxxxxx> wrote:
#define SET_ETHTOOL_OPS kcompat_set_ethtool_ops
#define DO_ETHTOOL_OPS /* duplicate net/core/ethtool.c, basically */
Where does kcompat_set_ethtool_ops store the pointer if
it does not exist in struct netdevice?
Inside an area allocated by the kcompat lib. SET_ETHTOOL_OPS takes
'struct net_device *' and 'struct ethtool_ops *' arguments, so it simply
needs to create a lookup list/table somewhere.
You keep asking for code, read kcompat :) kcompat_set_ethtool_ops has
exactly the same task as the 2.2.x-era backcompat implementation of
The perfect back-porting/back-compat system would magically make all
Linus-tree drivers work without any change on older kernels. I really
think the kcompat design is as close as you can come to that.
Here is a linux-kernel-friendly version of the kcompat design:
"naked struct derefs hurt. otherwise, happy hacking!"
And further, experience shows that the number of naked struct derefs
that matter is fairly small.
(Another less-common area that hurts besides naked-struct-deref is
function return type, which is why Linus created irqreturn_t)