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 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.