From: Jeff Garzik <jgarzik@pobox.com>
To: sfeldma@pobox.com
Cc: Gertjan van Wingerde <gwingerde@home.nl>,
netdev@oss.sgi.com, jkmaline@cc.hut.fi, jt@hpl.hp.com
Subject: Re: [RFC] Wireless extensions rethink
Date: Wed, 16 Jun 2004 15:49:26 -0400 [thread overview]
Message-ID: <40D0A446.8010607@pobox.com> (raw)
In-Reply-To: <1087412780.3351.34.camel@sfeldma-mobl2.dsl-verizon.net>
I apologize for not responding earlier...
ethtool is the wrong direction for a few reasons,
* I really should have done ethtool via netlink
* We want to move away from pretending that 802.3 == 802.11, and using
ethtool only serves to reinforce an association we don't want to make.
"everything is ethernet" isn't really true :)
About overall API design...
When designing interfaces that the low-level drivers must implement,
keep two things in mind:
* locking, security checks, and ioctl marshalling/thunking should be
done in common kernel code, not each hardware driver.
* given that, each wireless hook (callback) should be purpose-specific
-- which means each callback's arguments and return value vary,
depending on the callback's purpose. iw_handler must be killed, because
that forces more code than necessary to be in each low-level driver.
The example to look at here is struct ethtool_ops, and net/core/ethtool.c.
Low-level drivers should be implementing small, fine-grained hooks NOT
raw ioctl handlers. In addition to fostering smaller hardware drivers,
this insulates the driver interface from ABI changes to a certain degree.
Jeff
next prev parent reply other threads:[~2004-06-16 19:49 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-11 18:49 [RFC] Wireless extensions rethink Feldman, Scott
2004-06-15 16:39 ` Gertjan van Wingerde
2004-06-15 17:22 ` Vladimir Kondratiev
2004-06-16 9:13 ` Scott Feldman
2004-06-16 15:28 ` Gerald Britton
2004-06-16 17:40 ` Vladimir Kondratiev
2004-06-16 17:53 ` Scott Feldman
2004-06-16 19:06 ` Gerald Britton
2004-06-17 5:57 ` Luis R. Rodriguez
2004-06-16 17:46 ` Gertjan van Wingerde
2004-06-16 19:06 ` Scott Feldman
2004-06-16 19:49 ` Jeff Garzik [this message]
2004-06-16 22:25 ` Scott Feldman
2004-06-16 20:50 ` Jean Tourrilhes
2004-06-16 20:42 ` Jean Tourrilhes
2004-06-16 21:36 ` Jeff Garzik
2004-06-16 22:33 ` Jean Tourrilhes
2004-06-16 23:06 ` Jeff Garzik
2004-06-16 23:11 ` Jean Tourrilhes
2004-06-17 17:47 ` Jean Tourrilhes
2004-06-17 18:23 ` Jeff Garzik
2004-06-17 18:26 ` Jeff Garzik
2004-06-17 18:30 ` Gertjan van Wingerde
2004-06-17 18:51 ` Stephen Hemminger
2004-06-17 19:00 ` Jean Tourrilhes
2004-06-17 19:10 ` Jeff Garzik
2004-06-17 18:58 ` Jean Tourrilhes
2004-06-17 19:02 ` Jeff Garzik
2004-06-17 19:13 ` Jean Tourrilhes
2004-06-17 19:34 ` Jeff Garzik
2004-06-17 19:44 ` Jean Tourrilhes
2004-06-17 20:06 ` Jeff Garzik
2004-06-17 20:39 ` Jean Tourrilhes
2004-06-17 18:56 ` Jean Tourrilhes
2004-06-17 19:09 ` Jeff Garzik
2004-06-17 19:11 ` Jeff Garzik
2004-06-17 19:31 ` Jean Tourrilhes
2004-06-17 19:52 ` Jeff Garzik
2004-06-17 20:46 ` Jean Tourrilhes
2004-06-18 22:11 ` Andrew Morton
2004-06-18 22:54 ` Jeff Garzik
2004-06-16 22:48 ` Scott Feldman
-- strict thread matches above, loose matches on Subject: below --
2004-06-07 19:51 Gertjan van Wingerde
2004-06-07 20:52 ` Ben Greear
2004-06-07 18:33 Feldman, Scott
2004-06-07 18:39 ` Stephen Hemminger
2004-06-08 11:19 ` Herbert Xu
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=40D0A446.8010607@pobox.com \
--to=jgarzik@pobox.com \
--cc=gwingerde@home.nl \
--cc=jkmaline@cc.hut.fi \
--cc=jt@hpl.hp.com \
--cc=netdev@oss.sgi.com \
--cc=sfeldma@pobox.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.