From: Jeff Garzik <jgarzik@pobox.com>
To: "David S. Miller" <davem@redhat.com>
Cc: willy@debian.org, netdev@oss.sgi.com
Subject: Re: [PATCH] ethtool_ops rev 4
Date: Fri, 01 Aug 2003 19:35:20 -0400 [thread overview]
Message-ID: <3F2AF938.7050608@pobox.com> (raw)
In-Reply-To: <20030801160857.32ebbf22.davem@redhat.com>
David S. Miller wrote:
> On Fri, 01 Aug 2003 19:09:35 -0400
> Jeff Garzik <jgarzik@pobox.com> 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
pci_{get,set}_drvdata.
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)
Jeff
next prev parent reply other threads:[~2003-08-01 23:35 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-01 15:02 [PATCH] ethtool_ops rev 4 Matthew Wilcox
2003-08-01 15:40 ` Jeff Garzik
2003-08-01 15:46 ` Matthew Wilcox
2003-08-01 16:25 ` Jeff Garzik
2003-08-01 20:20 ` David S. Miller
2003-08-01 22:26 ` Jeff Garzik
2003-08-01 22:32 ` David S. Miller
2003-08-01 23:01 ` Jeff Garzik
2003-08-01 23:01 ` David S. Miller
2003-08-01 23:17 ` Jeff Garzik
2003-08-01 23:19 ` David S. Miller
2003-08-01 23:42 ` Jeff Garzik
2003-08-01 23:43 ` David S. Miller
2003-08-01 22:35 ` Jeff Garzik
2003-08-01 22:34 ` David S. Miller
2003-08-01 23:09 ` Jeff Garzik
2003-08-01 23:08 ` David S. Miller
2003-08-01 23:35 ` Jeff Garzik [this message]
2003-08-01 23:34 ` David S. Miller
2003-08-02 22:21 ` Matthew Wilcox
2003-08-02 22:34 ` Jeff Garzik
2003-08-03 0:27 ` Matthew Wilcox
2003-08-03 3:14 ` Jeff Garzik
2003-08-03 14:56 ` Matthew Wilcox
2003-08-03 17:09 ` Jeff Garzik
2003-08-05 14:32 ` Matthew Wilcox
2003-08-03 0:28 ` David S. Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3F2AF938.7050608@pobox.com \
--to=jgarzik@pobox.com \
--cc=davem@redhat.com \
--cc=netdev@oss.sgi.com \
--cc=willy@debian.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).