| To: | sfeldma@xxxxxxxxx |
|---|---|
| Subject: | Re: [RFC] Wireless extensions rethink |
| From: | Jeff Garzik <jgarzik@xxxxxxxxx> |
| Date: | Wed, 16 Jun 2004 15:49:26 -0400 |
| Cc: | Gertjan van Wingerde <gwingerde@xxxxxxx>, netdev@xxxxxxxxxxx, jkmaline@xxxxxxxxx, jt@xxxxxxxxxx |
| In-reply-to: | <1087412780.3351.34.camel@sfeldma-mobl2.dsl-verizon.net> |
| References: | <C6F5CF431189FA4CBAEC9E7DD5441E0103AF626C@orsmsx402.amr.corp.intel.com> <40CF263E.70009@home.nl> <1087377197.25912.54.camel@sfeldma-mobl2.dsl-verizon.net> <40D08769.3070106@home.nl> <1087412780.3351.34.camel@sfeldma-mobl2.dsl-verizon.net> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
| User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 |
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 :)
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 |
| Previous by Date: | Re: 2.6.7-rc3: unregister_netdevice: waiting for tun0 to become free. Usage count = 1, Alexey Kuznetsov |
|---|---|
| Next by Date: | MTU of related devices, Eble, Dan |
| Previous by Thread: | Re: [RFC] Wireless extensions rethink, Scott Feldman |
| Next by Thread: | Re: [RFC] Wireless extensions rethink, Scott Feldman |
| Indexes: | [Date] [Thread] [Top] [All Lists] |