netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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