From: Jeff Garzik <jgarzik@pobox.com>
To: Andrew Morton <akpm@osdl.org>
Cc: jt@hpl.hp.com, jt@bougret.hpl.hp.com, gwingerde@home.nl,
sfeldma@pobox.com, netdev@oss.sgi.com, jkmaline@cc.hut.fi
Subject: Re: [RFC] Wireless extensions rethink
Date: Fri, 18 Jun 2004 18:54:56 -0400 [thread overview]
Message-ID: <40D372C0.1020509@pobox.com> (raw)
In-Reply-To: <20040618151117.2f191d7f.akpm@osdl.org>
Andrew Morton wrote:
> Coming into this with my lateness exceeded only by my lack of context, I'd
> say that I share Jean's concern over making incompatible changes to the
> wireless user<->kernel interface at this time. If we can retain _both_
> interfaces in 2.6, remove the old one in 2.7 then maybe that'll be OK.
Two points:
1) This is about the _driver_ API. The userland interface is a
different issue. In Linux the userland ABI is a holy grail that
shouldn't be broken without warnings across major kernel versions. We
can easily add netlink support (as Jean demonstrated) without
2) I won't break the stable kernel driver API, so you worries here are
unfounded.
> But I do wonder whether this API is the uppermost issue with the wireless
> drivers.
The driver API has got to go. Period. Just look at what a sample
driver exports:
> static const struct iw_handler_def wavelan_handler_def =
> {
> .num_standard = sizeof(wavelan_handler)/sizeof(iw_handler),
> .num_private = sizeof(wavelan_private_handler)/sizeof(iw_handler),
> .num_private_args = sizeof(wavelan_private_args)/sizeof(struct iw_priv_args),
> .standard = (iw_handler *) wavelan_handler,
> .private = (iw_handler *) wavelan_private_handler,
> .private_args = (struct iw_priv_args *) wavelan_private_args,
> .spy_offset = ((void *) (&((net_local *) NULL)->spy_data) -
> (void *) NULL),
> };
It flat out doesn't work with object lifetime rules, taking _offsets_ in
driver-local structs into more generic code.
As for the wireless drivers themselves, they will change as the HostAP
stuff gets integrated more closely into the kernel.
> There seem to be a lot of bug reports, and these drivers are
> *really* complex, and there are lots of out-of-tree drivers. Aren't these
> the things which we should be devoting cycles to?
The driver API is one of the causes of complexity. Lack of direct
integration into the net stack (see
http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/davem-p80211.tar.bz2
for an example direction) another cause of the complexity.
As for out of tree drivers, just look at the web page. Most either (a)
have binary-only BLOBs associated or (b) duplicate existing drivers N
times. Outside the kernel tree there is no unification, but 3-4 drivers
for _every_ wireless chipset.
Jeff
next prev parent reply other threads:[~2004-06-18 22:54 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
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 [this message]
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=40D372C0.1020509@pobox.com \
--to=jgarzik@pobox.com \
--cc=akpm@osdl.org \
--cc=gwingerde@home.nl \
--cc=jkmaline@cc.hut.fi \
--cc=jt@bougret.hpl.hp.com \
--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 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).