State of the Union - Wireless
January 5, 2006
Another banner year has passed, with Linux once again proving
its superiority in the area of crappy wireless (WiFi) support.
Linux oldsters love the current state of wireless, because it hearkens
back to the heady days of Yuri Gagarin, Sputnik and Linux kernel 0.99,
when getting hardware to work under Linux required either engineering
knowledge or luck (or both).
Linux has made remarkable progress in the area of hardware support,
in the past five years, reaching a state where it is unusual for
mainstream hardware to -not- be supported by Linux as soon as it
is released. Unfortunately, this does not extend to wireless.
Wireless drivers today are scattered to the four winds: many
are in-tree, but for older hardware, and lack active maintainers.
They work. A few drivers exist for "relatively" modern WiFi hardware
in-tree; they work, but they don't have active maintainers either.
Current hardware, many of it "softmac", is driven by a wild variety of
drivers, for a wide variety of wireless stacks, none of them in-tree.
Or, the in-tree drivers are simply out of date versions of actively
maintained out-of-tree drivers. In one or two cases, users have turned
to awful emulation solutions like NdisWrapper. But can you blame them?
They just want their hardware to work.
Twelve months ago, the community consensus was that the best basis for
a wireless stack was HostAP, or as it turned out, a HostAP derivative
whose sole users are the Intel ipw drivers. So that got merged.
Now, twelve months later, fashion has changed, ieee80211 lost a lot of
momentum, and it seems that the DeviceScape wireless stack is all the
rage, and there are convincing arguments for merging the DeviceScape
code floating about.
But you -- I'm talking to all you wireless kernel hackers -- need to
come up with some solutions for some key issues:
* We really have no wireless maintainer. I'm just the defacto guy,
with no interest in the job. The ideal maintainer knows 802.11 well,
uses git, and isn't an asshole with no taste. I'm just the guy who
wants to make sure the net driver portion doesn't turn out to be a
stinker (read: review and pass up the chain).
* Once you pick your favorite stack, STICK WITH IT. In Linux, there
is collectively very little patience with a rewrite every 12 months,
particularly one that is dropped in out of the blue rather then
evolved out of existing code.
In Linux, today's wireless code will probably live at least 10 years,
if not more. Long term maintainability is paramount. This is
why we prefer to evolve code, rather than constantly rewrite it.
Rewrites are often improvements, but bring in their own wave of
bugs and incompatibilities, while eliminating years of carefully
culminated knowledge buried in the existing code. As a solution,
pragmatic users wind up running both the pre-rewrite code and the
new code -- duplicate code. Code duplication in turn brings in its
own wave of bugs, and assaults on open source's economies of scale.
* Wireless drivers and the wireless stack need to be maintained IN-TREE
as a COLLECTIVE ENTITY, not piecemeal maintenance as its done now.
The whole point of working in-tree, the whole point of this open source
thing is that everybody works on the same code, and the entire Internet
is your test bed. Quality improves the more people work together.
The entire Linux kernel engineering process is focused on getting core
kernel code out to distributions (then to end users) and power users.
Out-of-tree code breaks that model, breaking the It Just Works(tm)
theme applicable to other Linux-supported hardware.
* Release early, release often. Pushing from an external repository to
the official kernel tree every few months creates more problems
than it solves. Out-of-tree drivers fail to take advantage of
recent kernel changes and coding practices, which leads to bugs and
incompatibilities. Slow pushing leads to huge periodic updates,
which are awful for debugging, testing, and general use.
* Wireless management, in particular the wireless kernel<->user
interface, needs some thinking. Wireless Extensions (WE) isn't
cutting it, but I haven't seen any netlink work yet (or some
other interface). Whatever the userspace interface is, it will be
basically carved in stone for years (unlike kernel APIs), so this
needs a lot more thought than people have been giving it.
* ALL wireless stacks need work. It is currently fashionable to laud
DeviceScape and trash in-kernel ieee80211, but outside of the
cheerleading, BOTH have real technical issues that need addressing.
IOW, no matter what code is chosen, _somebody_ is on the hook for
a fair amount of work. A switch is not without its costs.
* I would prefer that people patch the in-tree ieee80211 code,
probably in the direction of Jiri Benc's proposed ieee80211_device
direction. I take patches from all parties, not just Intel.
* However, if the engineering reasons for switching to DeviceScape
or another wireless stack are powerful enough to overcome Linux's
"no big patches, evolve it" maxim, great! But make sure to work
on converting drivers to this new stack. The wireless drivers and
wireless stack should evolve in tandem. Otherwise, drivers get
left behind, grow moldy, and Linux users suffer.
* Feel free to submit radical changes -- wireless is yet young --
just make sure all drivers keep working from release to release.
* Long term, wireless should go from being a library of common code to a
"real" wireless stack, as shown in the template developed by David Miller:
http://kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/davem-p80211.tar.bz2
Zhu Yi @ Intel and Vladmir @ somewhere both independently did some
work in this area.
* Please CC wireless stack/driver discussions to [email protected]
mailing list, rather than everybody hiding in their own little
corner.
* I prefer GPL-only code. Dual licensing has proven in practice to
be a logistical nightmare that concentrates power in the hands of
a few. Dual licensing, BSD licensing works for some, but GPL-only
code is quite simply the least amount of flamewars, headaches
and worry. IOW, the P.I.T.A. level of GPL-only code is lowest.
Open source is about not only merit, but lack of control. If I am
being a knucklehead, or you just don't like me, you can always go
through Andrew Morton, David Miller, Linus, ... With dual licensed
code, engineers are really really really really encouraged to submit
code through a single channel for legal rather than merit reasons.
Dual licensed code gives kernel hackers yet more legal crapola to
worry about, which is never a good thing.
Patches welcome from all motivated, clueful parties. Jiri Benc has a
long series of patches that looks nice. Johannes Berg has done some
work on the ieee80211 softmac stuff and hw WEP. But maybe DeviceScape
is what people like now.
So... there it is. We suck. There's hope. No Luke Skywalker in sight.
I hope we can avoid being slaves to fashion, by merging a rewrite, but
that way be the way to go.
Jeff
Jeff Garzik wrote:
> * Release early, release often. Pushing from an external repository to
> the official kernel tree every few months creates more problems
> than it solves. Out-of-tree drivers fail to take advantage of
> recent kernel changes and coding practices, which leads to bugs and
> incompatibilities. Slow pushing leads to huge periodic updates,
> which are awful for debugging, testing, and general use.
I think this is an especially big problem, from a user's perspective at
least.. I'm tired of patching up my laptop kernel with the latest
ieee80211 and ipw2200 on every update because the mainline kernel
contains an ancient version which is almost useless to me, and the Intel
guys apparently don't feel like merging newer versions upstream until
they get it perfect, or something..
I'm sure this would make it easier for other driver developers to work
with the ieee80211 stack as well, if the current version wasn't
maintained entirely out of tree for all intents and purposes..
The other complaint I have is that there's just too much breakage
happening.. you update the wireless driver, then you have to update the
wireless tools, then maybe WPA Supplicant stops working, etc. etc.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
On Thu, 05 Jan 2006 23:39:07 -0600 Robert Hancock wrote:
btw, what happened to the netdev list copy??
thanx,
---
~Randy
On Friday 06 January 2006 05:39, Robert Hancock wrote:
> Jeff Garzik wrote:
> > * Release early, release often. Pushing from an external repository to
> > the official kernel tree every few months creates more problems
> > than it solves. Out-of-tree drivers fail to take advantage of
> > recent kernel changes and coding practices, which leads to bugs and
> > incompatibilities. Slow pushing leads to huge periodic updates,
> > which are awful for debugging, testing, and general use.
>
> I think this is an especially big problem, from a user's perspective at
> least.. I'm tired of patching up my laptop kernel with the latest
> ieee80211 and ipw2200 on every update because the mainline kernel
> contains an ancient version which is almost useless to me, and the Intel
> guys apparently don't feel like merging newer versions upstream until
> they get it perfect, or something..
Robert, this was _one_ kernel, 2.6.14, and has since been rectified. Install
2.6.15 and be happy with your bleeding edge driver supporting firmware 2.4.
The last thing we need is Yet Another Flame War about the ipw2x00 drivers.
They're some of the best drivers in the wireless tree.
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
On Fri, 2006-01-06 at 12:00 +0100, Michael Buesch wrote:
> * "master" interface as real device node
> * Virtual interfaces (net_devices)
I didn't want to spam the netdev wiki with this (yet) so I collected
some more structured things outside. Anyone feel free to edit:
http://softmac.sipsolutions.net/802.11
I'll move that content to the netdev wiki if anyone else thinks it would
be a good way forward to start with requirements, API issues and
similar.
Until we get there, we'll fix up softmac to make it usable for most
people in basic station mode without any kind of virtual devices, which
will need some slight changes to the current ieee80211.
johannes
On Fri, Jan 06, 2006 at 12:31:24PM +0100, Johannes Berg wrote:
> On Fri, 2006-01-06 at 12:00 +0100, Michael Buesch wrote:
>
> > * "master" interface as real device node
> > * Virtual interfaces (net_devices)
>
> I didn't want to spam the netdev wiki with this (yet) so I collected
> some more structured things outside. Anyone feel free to edit:
> http://softmac.sipsolutions.net/802.11
>From someone who has no idea at all (yet) about 802.11: why character
device, and not sysfs or configfs files? Like
TASK: get list of MAC addresses available to hardware device (usually only one for current hw)
cat /sys/devices/path/to/device/wireless/address
TASK: get list of virtual devices including (some of) their properties
ls -l /sys/devices/path/to/device/wireless/
...
wlan0 -> /sys/class/net/wlan0
wlan1 -> /sys/class/net/wlan1
TASK: create virtual device (with arbitrary type, netdev name and mac address)
^^^^^^
isn't nameif / udev for that?
echo "$type" > /sys/devices/path/to/device/wireless/new_if
... we get uevents for this new interface; in this we can set the
mac adress doing:
echo "$mac" > /sys/class/net/wlan0/wireless/address
TASK: configure virtual device (key is the device name since that needs to be unique anyway)
echo "$some_config_option_for_virtual_device" > /sys/class/net/wlan0/wireless/some_option
echo "$some_config_option_for_physical_device"> /sys/devices/path/to/dev/wireless/some_other_option
Of course the configuration userspace tool would use libsysfs for that, not
"echo" scripts... but they'd work too.
Dominik
> From someone who has no idea at all (yet) about 802.11: why character
> device, and not sysfs or configfs files? Like
As Michael already said -- there's no real reason for that. We were just
brainstorming. The /dev idea seemed like a good plan at first, but then
it isn't fixed. What you suggested below does look useful too.
Coming back to the point Michael already raised: the overarching idea is
to get rid of the net_dev for the 'master' device, even if the
underlying hardware supports only a single virtual device (which might
then be created by the driver automatically)
I'll move the wiki pages a bit to accomodate different models, please
check in a few minutes.
johannes
Am Freitag 06 Januar 2006 12:46 schrieb Dominik Brodowski:
> From someone who has no idea at all (yet) about 802.11: why character
> device, and not sysfs or configfs files? Like
sysfs shares the main problem with wireless extensions: It configures one
value per file / per ioctl. Setting up a wireless card to associate or form
an IBSS network consists of multiple parameters, many requiring the card to
disasscociate.
With hardware like prism2 usb that gets "don't touch me now mode" for a while
after a join command is issued, current API requires a driver to delay
starting an association in order to wait if other config requests are issued
- an ugly hack.
I vote for netlink. It's a defined and tested interface and has all features
needed to set multiple values in one transaction.
Stefan
On Fri, 2006-01-06 at 13:48 +0100, Stefan Rompf wrote:
> With hardware like prism2 usb that gets "don't touch me now mode" for a while
> after a join command is issued, current API requires a driver to delay
> starting an association in order to wait if other config requests are issued
> - an ugly hack.
So that settles the 'need to change multiple settings at once' issue,
saying that yes, it is indeed required.
johannes
On Friday 06 January 2006 13:31, Johannes Berg wrote:
> On Fri, 2006-01-06 at 12:00 +0100, Michael Buesch wrote:
>
> > * "master" interface as real device node
> > * Virtual interfaces (net_devices)
>
> I didn't want to spam the netdev wiki with this (yet) so I collected
> some more structured things outside. Anyone feel free to edit:
> http://softmac.sipsolutions.net/802.11
I am confused.
There is
http://softmac.sipsolutions.net/softmac-snapshot.tar.bz2
at http://softmac.sipsolutions.net/SoftMAC,
page also says "Projects using this layer: * Broadcom 43xx driver"
but Broadcom driver page at ftp://ftp.berlios.de/pub/bcm43xx/snapshots/softmac/
has ftp://ftp.berlios.de/pub/bcm43xx/snapshots/softmac/ieee80211softmac-20060107.tar.bz2
which is not the same. For example, ieee80211softmac.h file exists in both
tarballs but is not identical.
Suppose one wants to use softmac in a project. What tarball contains
the bleeding edge of softmac?
> I'll move that content to the netdev wiki if anyone else thinks it would
> be a good way forward to start with requirements, API issues and
> similar.
>
> Until we get there, we'll fix up softmac to make it usable for most
> people in basic station mode without any kind of virtual devices, which
> will need some slight changes to the current ieee80211.
--
vda
On Friday 06 January 2006 06:22, Jeff Garzik wrote:
>
> State of the Union - Wireless
> January 5, 2006
[ snip ]
> * Wireless drivers and the wireless stack need to be maintained IN-TREE
> as a COLLECTIVE ENTITY, not piecemeal maintenance as its done now.
>
> The whole point of working in-tree, the whole point of this open source
> thing is that everybody works on the same code, and the entire Internet
> is your test bed. Quality improves the more people work together.
> The entire Linux kernel engineering process is focused on getting core
> kernel code out to distributions (then to end users) and power users.
> Out-of-tree code breaks that model, breaking the It Just Works(tm)
> theme applicable to other Linux-supported hardware.
Cool, so may I please know why acx driver is not included in the mainline?
In case it needs more work, well, (a) at least tell us what exactly
you want improved, and (b) why do you think that in-tree acx would not
be improved? It will get more visibility, maybe some people will
get interested and will send a patch or two to us...
> * Release early, release often. Pushing from an external repository to
> the official kernel tree every few months creates more problems
> than it solves. Out-of-tree drivers fail to take advantage of
> recent kernel changes and coding practices, which leads to bugs and
> incompatibilities. Slow pushing leads to huge periodic updates,
> which are awful for debugging, testing, and general use.
I want to avoid exactly this, and therefore want acx in mainline.
> * ALL wireless stacks need work. It is currently fashionable to laud
> DeviceScape and trash in-kernel ieee80211, but outside of the
> cheerleading, BOTH have real technical issues that need addressing.
> IOW, no matter what code is chosen, _somebody_ is on the hook for
> a fair amount of work. A switch is not without its costs.
>
> * I would prefer that people patch the in-tree ieee80211 code,
> probably in the direction of Jiri Benc's proposed ieee80211_device
> direction. I take patches from all parties, not just Intel.
>
> * However, if the engineering reasons for switching to DeviceScape
> or another wireless stack are powerful enough to overcome Linux's
> "no big patches, evolve it" maxim, great! But make sure to work
> on converting drivers to this new stack. The wireless drivers and
> wireless stack should evolve in tandem. Otherwise, drivers get
> left behind, grow moldy, and Linux users suffer.
How are we going to find out which stack is best and which stack
we should concentrate our efforts on? In an absense of wifi maintainer,
maybe we should throw _all stacks_ (currently two) into the mainline,
and evolution will find the best one. Yes, it would be a bit ugly
at first, but I hope it will speed up evolution a lot.
Let current stack sit in include/net/ieee80211*.h and net/ieee80211/*,
add dcape one into include/net/wlan*.h and net/wlan/*
(s/wlan/dscape/ or whatever)
We can even give Devicescape folks blanket permissions to
maintain their stack in include/net/wlan*.h and net/wlan/*.
Maybe they can act as a wifi maintainer long term.
Existing drivers won't need to closely track every change
in dscape stack. If dscape will survive, old drivers can be
converted to it gradually. If not, just dike it out.
> * Feel free to submit radical changes -- wireless is yet young --
> just make sure all drivers keep working from release to release.
>
> * Long term, wireless should go from being a library of common code to a
> "real" wireless stack, as shown in the template developed by David Miller:
> http://kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/davem-p80211.tar.bz2
> Zhu Yi @ Intel and Vladmir @ somewhere both independently did some
> work in this area.
>
> * Please CC wireless stack/driver discussions to [email protected]
> mailing list, rather than everybody hiding in their own little
> corner.
[snip]
> So... there it is. We suck. There's hope. No Luke Skywalker in sight.
> I hope we can avoid being slaves to fashion, by merging a rewrite, but
> that way be the way to go.
--
vda
On Tuesday 10 January 2006 00:39, Denis Vlasenko wrote:
> How are we going to find out which stack is best and which stack
> we should concentrate our efforts on? In an absense of wifi maintainer,
> maybe we should throw _all stacks_ (currently two) into the mainline,
> and evolution will find the best one. Yes, it would be a bit ugly
> at first, but I hope it will speed up evolution a lot.
>
> Let current stack sit in include/net/ieee80211*.h and net/ieee80211/*,
> add dcape one into include/net/wlan*.h and net/wlan/*
> (s/wlan/dscape/ or whatever)
>
> We can even give Devicescape folks blanket permissions to
> maintain their stack in include/net/wlan*.h and net/wlan/*.
> Maybe they can act as a wifi maintainer long term.
>
> Existing drivers won't need to closely track every change
> in dscape stack. If dscape will survive, old drivers can be
> converted to it gradually. If not, just dike it out.
I don't like the idea of maintaining two of anything. What if I have two
wireless interfaces, each using a different stack?
Performance--,
Kernel size++
I get that it's hard to get everyone to agree on one stack or another, but we
need to make the decision now because the longer we don't have a decision
made (this includes maintaining two in-tree stacks) the longer it's going to
take us to have serious / robust / reliable / consistent wireless support.
I know basically nothing about 802.11, but it seems to me that what should
happen is that if there is sufficient motivation to boot ieee80211 in favor
of DeviceScape, someone should cook up the patches.
Besides, assume we did bless two stacks. Every new driver / driver that wanted
to go mainline would choose one or another (it's already clear that people
disagree). Thus we end up with *more* work to do in order to decide one way
or another (since we have to partially break & fully port all the drivers
from one stack to another).
There's incompatibility all over this wireless landscape. The best way to deal
with it is to make all the big hard decisions now - say "this is the way it's
going to be" and work from there. We can always undo mistakes later, but
we'll never get to that point if we don't start moving in one direction
instead of ten.
> --
> vda
> -
Cheers,
Chase
Hi,
On Tue, Jan 10, 2006 at 08:39:25AM +0200, Denis Vlasenko wrote:
> On Friday 06 January 2006 06:22, Jeff Garzik wrote:
> >
> > State of the Union - Wireless
> > January 5, 2006
>
> [ snip ]
>
> > * Wireless drivers and the wireless stack need to be maintained IN-TREE
> > as a COLLECTIVE ENTITY, not piecemeal maintenance as its done now.
> >
> > The whole point of working in-tree, the whole point of this open source
> > thing is that everybody works on the same code, and the entire Internet
> > is your test bed. Quality improves the more people work together.
> > The entire Linux kernel engineering process is focused on getting core
> > kernel code out to distributions (then to end users) and power users.
> > Out-of-tree code breaks that model, breaking the It Just Works(tm)
> > theme applicable to other Linux-supported hardware.
>
> Cool, so may I please know why acx driver is not included in the mainline?
> In case it needs more work, well, (a) at least tell us what exactly
> you want improved, and (b) why do you think that in-tree acx would not
> be improved? It will get more visibility, maybe some people will
> get interested and will send a patch or two to us...
I think wording is a tad bit too aggressive here, since we (well, at least me)
haven't made many efforts to get it included, since we had to work out
some things. However at this point we should really go for inclusion,
the sooner the better (right?).
> > * Release early, release often. Pushing from an external repository to
> > the official kernel tree every few months creates more problems
> > than it solves. Out-of-tree drivers fail to take advantage of
> > recent kernel changes and coding practices, which leads to bugs and
> > incompatibilities. Slow pushing leads to huge periodic updates,
> > which are awful for debugging, testing, and general use.
>
> I want to avoid exactly this, and therefore want acx in mainline.
ACK.
> How are we going to find out which stack is best and which stack
> we should concentrate our efforts on? In an absense of wifi maintainer,
> maybe we should throw _all stacks_ (currently two) into the mainline,
> and evolution will find the best one. Yes, it would be a bit ugly
> at first, but I hope it will speed up evolution a lot.
I have to admit that a big item on our acx ToDo list was the missing ieee80211
integration, but now that there's a second stack on the horizon and things
look less decided I'm not that much troubled by our lack of ieee80211 use
any more ;)
That said, of course we should try to get rid of our own, historic (originating
from binary TI driver!) in-driver stack very soon.
I won't do any comments on which stack to use, though, I will do research first
and then work out which one to use depending on popularity and features
matching our chips' properties.
Andreas Mohr
>
> I don't like the idea of maintaining two of anything. What if I have two
> wireless interfaces, each using a different stack?
>
> Performance--,
> Kernel size++
>
> I get that it's hard to get everyone to agree on one stack or another, but we
> need to make the decision now because the longer we don't have a decision
> made (this includes maintaining two in-tree stacks) the longer it's going to
> take us to have serious / robust / reliable / consistent wireless support.
This is exactly the opposite of what Linus proposes in his management
style document: "Avoid making decisions". At the moment, nobody seems to
know what the "right" direction is, because the right direction is the
one that will produce the better wireless support, and not the one that
sounds better at the moment.
I therefore also vote for merging both stacks.
> We can always undo mistakes later, but
> we'll never get to that point if we don't start moving in one direction
> instead of ten.
You were right if there were ten, but there seem to be only two at the
moment. One stack will survive and one will die. There's no point in
deciding this now.
Tim
On Tue, Jan 10, 2006 at 01:38:58PM +0100, Tim Tassonis wrote:
>...
> >We can always undo mistakes later, but
> >we'll never get to that point if we don't start moving in one direction
> >instead of ten.
>
> You were right if there were ten, but there seem to be only two at the
> moment. One stack will survive and one will die. There's no point in
> deciding this now.
No, we'll end up with two stacks, some drivers using the first stack and
some the second one.
You can't simply let one stack die because this would imply either
rewriting all drivers using this stack or dropping support for some
hardware.
> Tim
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Denis Vlasenko wrote:
> I am confused.
Which isn't really all that surprising.
> ftp://ftp.berlios.de/pub/bcm43xx/snapshots/softmac/ieee80211softmac-20060107.tar.bz2
> which is not the same. For example, ieee80211softmac.h file exists in both
> tarballs but is not identical.
>
> Suppose one wants to use softmac in a project. What tarball contains
> the bleeding edge of softmac?
The one from the softmac page is created from the git repository. The one
on the bcm page is created from the now historical mercurial archive.
I need to get the bcm people to take away that snapshot and link to the
correct one.
johannes
Adrian Bunk wrote:
> On Tue, Jan 10, 2006 at 01:38:58PM +0100, Tim Tassonis wrote:
>> ...
>>> We can always undo mistakes later, but
>>> we'll never get to that point if we don't start moving in one direction
>>> instead of ten.
>> You were right if there were ten, but there seem to be only two at the
>> moment. One stack will survive and one will die. There's no point in
>> deciding this now.
>
> No, we'll end up with two stacks, some drivers using the first stack and
> some the second one.
>
> You can't simply let one stack die because this would imply either
> rewriting all drivers using this stack or dropping support for some
> hardware.
By "die", I didn't mean "delete it from kernel sources".
It is very probable that over time, the "winning" stack will contain
most drivers for the most common hardware, and the "losing" one just a
few obscure ones. The "losing" one will still be available for people
using hardware only supported by that stack.
Like the OSS/Alsa or XFree3.x/XFree4.x situations.
Tim
On Tue, Jan 10, 2006 at 02:34:00PM +0100, Tim Tassonis wrote:
> Adrian Bunk wrote:
> >On Tue, Jan 10, 2006 at 01:38:58PM +0100, Tim Tassonis wrote:
> >>...
> >>>We can always undo mistakes later, but
> >>>we'll never get to that point if we don't start moving in one direction
> >>>instead of ten.
> >>You were right if there were ten, but there seem to be only two at the
> >>moment. One stack will survive and one will die. There's no point in
> >>deciding this now.
> >
> >No, we'll end up with two stacks, some drivers using the first stack and
> >some the second one.
> >
> >You can't simply let one stack die because this would imply either
> >rewriting all drivers using this stack or dropping support for some
> >hardware.
>
> By "die", I didn't mean "delete it from kernel sources".
>
> It is very probable that over time, the "winning" stack will contain
> most drivers for the most common hardware, and the "losing" one just a
> few obscure ones. The "losing" one will still be available for people
> using hardware only supported by that stack.
>
> Like the OSS/Alsa or XFree3.x/XFree4.x situations.
And OSS/ALSA is an example why this is not a good thing:
- OSS in the kernel is unmaintained
- people forced to use OSS drivers can't use applications only
supporting ALSA
In the OSS/ALSA case this was not avoidable since OSS was for a long
time the sound system in the kernel, and ALSA came later.
But if you have the possibility to choose which stack to use at the
beginning (as in the wireless case), the only reasonable solution is to
choose _one_ stack.
> Tim
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Tuesday 10 January 2006 06:38, Tim Tassonis wrote:
> This is exactly the opposite of what Linus proposes in his management
> style document: "Avoid making decisions". At the moment, nobody seems to
> know what the "right" direction is, because the right direction is the
> one that will produce the better wireless support, and not the one that
> sounds better at the moment.
I won't try to speak for Linus (perhaps he'd like to pipe up at some point),
but I think you're pulling that concept wayy out of context here.
Quoting ManagementStyle:
> Btw, another way to avoid a decision is to plaintively just whine "can't
> we just do both?" and look pitiful. Trust me, it works. If it's not
> clear which approach is better, they'll eventually figure it out. The
> answer may end up being that both teams get so frustrated by the
> situation that they just give up.
Built into that paragraph, I think, is the assumption that you never 'do
both'.
Also, referring to OSS/Alsa is just a great way to illustrate the problem with
your idea. There is, today, finally a "dominant" solution, but how long did
it take us to get there? By my count, a really long time! And along the way
we've had to deal with all kinds of applications that just support the first
and not the other. And it seems like far too many people still have just one
foot in the door - take for instance the README files shipped with commercial
game ports that advise using OSS at the first hint of trouble with Alsa.
Is this what we want for wireless?
>
> Tim
>
Chase
Adrian Bunk wrote:
> On Tue, Jan 10, 2006 at 02:34:00PM +0100, Tim Tassonis wrote:
>> Like the OSS/Alsa or XFree3.x/XFree4.x situations.
>
> And OSS/ALSA is an example why this is not a good thing:
> - OSS in the kernel is unmaintained
Because it is dead, yes...
> - people forced to use OSS drivers can't use applications only
> supporting ALSA
That is another problem. The problem is different API's. With networking
drivers, that should really not be a problem once the device is up. You
don't speak differently to different network devices, so applications
will just do fine.
> But if you have the possibility to choose which stack to use at the
> beginning (as in the wireless case), the only reasonable solution is to
> choose _one_ stack.
... _if_ you have the possibility, yes. But you might end up having
chosen the wrong one. There is a reason why two stacks exist.
Tim
>
> I won't try to speak for Linus (perhaps he'd like to pipe up at some point),
> but I think you're pulling that concept wayy out of context here.
>
> Quoting ManagementStyle:
>
>> Btw, another way to avoid a decision is to plaintively just whine "can't
>> we just do both?" and look pitiful. Trust me, it works. If it's not
>> clear which approach is better, they'll eventually figure it out. The
>> answer may end up being that both teams get so frustrated by the
>> situation that they just give up.
>
> Built into that paragraph, I think, is the assumption that you never 'do
> both'.
Well, we'd have to ask Linus about this one. I think it can be a good
idea to do both, if you're not sure which one is better.
>
> Also, referring to OSS/Alsa is just a great way to illustrate the problem with
> your idea. There is, today, finally a "dominant" solution, but how long did
> it take us to get there? By my count, a really long time! And along the way
> we've had to deal with all kinds of applications that just support the first
> and not the other. And it seems like far too many people still have just one
> foot in the door - take for instance the README files shipped with commercial
> game ports that advise using OSS at the first hint of trouble with Alsa.
A network device is way better abstracted by the operating system, so
compatibility issues are of much smaller concern.
> Is this what we want for wireless?
We wouldn't get it, see above.
On Tue, Jan 10, 2006 at 05:07:26PM +0100, Tim Tassonis wrote:
> Adrian Bunk wrote:
> >On Tue, Jan 10, 2006 at 02:34:00PM +0100, Tim Tassonis wrote:
> >>Like the OSS/Alsa or XFree3.x/XFree4.x situations.
> >
> >And OSS/ALSA is an example why this is not a good thing:
> >- OSS in the kernel is unmaintained
>
> Because it is dead, yes...
And this is exactly what you predicted for one of the merged stacks.
>...
> >But if you have the possibility to choose which stack to use at the
> >beginning (as in the wireless case), the only reasonable solution is to
> >choose _one_ stack.
>
> ... _if_ you have the possibility, yes. But you might end up having
> chosen the wrong one. There is a reason why two stacks exist.
The decision was already in the past - there is one stack that is
already merged.
The question is whether there is a different stack that is considered
that much better that switching to this stack including converting all
drivers is worth the effort.
In the short term, having different stacks with different features and
deficites only creates confusion.
In the long term, different stacks in the kernel will be a maintenance
nightmare.
> Tim
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Tue, 10 Jan 2006 13:53:57 +0100, Adrian Bunk <[email protected]> wrote:
> On Tue, Jan 10, 2006 at 01:38:58PM +0100, Tim Tassonis wrote:
> >...
> > >We can always undo mistakes later, but
> > >we'll never get to that point if we don't start moving in one direction
> > >instead of ten.
> >
> > You were right if there were ten, but there seem to be only two at the
> > moment. One stack will survive and one will die. There's no point in
> > deciding this now.
>
> No, we'll end up with two stacks, some drivers using the first stack and
> some the second one.
>
> You can't simply let one stack die because this would imply either
> rewriting all drivers using this stack or dropping support for some
> hardware.
So, you don't want to remove OSS drivers anymore, I take it.
Can't let bad stacks die!
-- Pete
On Tue, Jan 10, 2006 at 04:03:24PM -0800, Pete Zaitcev wrote:
> On Tue, 10 Jan 2006 13:53:57 +0100, Adrian Bunk <[email protected]> wrote:
> > On Tue, Jan 10, 2006 at 01:38:58PM +0100, Tim Tassonis wrote:
> > >...
> > > >We can always undo mistakes later, but
> > > >we'll never get to that point if we don't start moving in one direction
> > > >instead of ten.
> > >
> > > You were right if there were ten, but there seem to be only two at the
> > > moment. One stack will survive and one will die. There's no point in
> > > deciding this now.
> >
> > No, we'll end up with two stacks, some drivers using the first stack and
> > some the second one.
> >
> > You can't simply let one stack die because this would imply either
> > rewriting all drivers using this stack or dropping support for some
> > hardware.
>
> So, you don't want to remove OSS drivers anymore, I take it.
> Can't let bad stacks die!
There are OSS drivers in the kernel that support hardware not supported
by ALSA.
> -- Pete
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
A few days ago, Jeff Garzik reminded us all of the grossly imperfect
state of wireless (802.11 aka WiFi) networking in Linux. First in
his list of key issues was the lack of a permanent maintainer for the
kernel wireless code. Jeff approached me to see if I was interested
in that role, and after some discussions with Jeff and others I have
agreed to assume it. Consequently...
I hereby claim responsibility for the state of wireless networking
support in the Linux kernel.
By that statement I do not mean to claim credit for that which has
already been done. Nor do I shoulder the blame for any missteps which
have occurred to date. I simply mean that I intend to do my best to
improve the wireless networking support in Linux at an observable rate
for the foreseeable future. I intend to do that both through my own
work and through facilitating and/or coordinating the work of others.
I intend to do so with the ultimate goal of achieving the same sort of
"best of breed" networking support for wireless that Linux already
enjoys in traditional networking technologies. I hope that I can
count on all of you for development, testing, and/or moral support
in that endeavour.
Who am I?
Hopefully many of you recognize me through my upstream contributions.
Others may have seen some of my work with Fedora and/or RHEL
(http://people.redhat.com/linville/). My recent announcement of
the Fedora-netdev line of kernels seems to have drawn a fair amount
of publicity.
Beyond that, I have spent a decade or so in networking, mostly with
LAN switches. I have good experience with LAN technologies, including
Token Ring, ATM, and especially Ethernet. I have considerably less
experience with 802.11, but I am building on that as quickly as I can.
I have no doubt that there are many with more 802.11 expertise than
I have. Still, I believe that I have enough expertise to combine with
my judgment and experience in order to carry-out this duty effectively.
Maintenance Plans
I will, of course, establish a public GIT tree to act as a repository
for wireless development. I have requested space at kernel.org, and
I will announce that location once the tree is established. In the
meantime, please copy me on any wireless and/or wireless-related
patches you may submit to make sure that I see them.
If you are the maintainer of an out-of-tree driver or other component
(e.g. softmac), please let me hear from you (publicly or privately).
I want to be sure to identify all the major stakeholders. I would
also like to hear your plans for getting your code into the tree... :-)
I realize there are some burning issues at the moment, especially the
DeviceScape vs. ieee80211 stack wars. I do not intend to pronounce
summary judgment on any issues here or in the immediate future.
Please do copy me on any important discussions, and feel free to
invite me into any pertinent mailing lists or IRC channels. I would
also love to hear about any ongoing projects, even if they may not
be ready to be discussed publicly.
Once again, I appreciate your support in this. I thank Jeff for the
role he has played to date and the role he will continue to play.
Likewise I thank all of the wireless contributors, including driver,
stack, and userland tool maintainers. I hope to enjoy your continued
contributions and your support.
May the Force be with us!
John
--
John W. Linville
[email protected]
From: "John W. Linville" <[email protected]>
Date: Tue, 10 Jan 2006 21:05:36 -0500
> I hereby claim responsibility for the state of wireless networking
> support in the Linux kernel.
Thanks for taking on this important role John. It is truly
appreciated. Even though it may end up feeling like a thankless job
at times, I do hope you stick with it :-)
John W. Linville wrote:
> I realize there are some burning issues at the moment, especially the
> DeviceScape vs. ieee80211 stack wars. I do not intend to pronounce
> summary judgment on any issues here or in the immediate future.
> Please do copy me on any important discussions, and feel free to
> invite me into any pertinent mailing lists or IRC channels. I would
> also love to hear about any ongoing projects, even if they may not
> be ready to be discussed publicly.
Thanks for working on this... :)
Jeff
On Tue, 2006-01-10 at 21:05 -0500, John W. Linville wrote:
> If you are the maintainer of an out-of-tree driver or other component
> (e.g. softmac), please let me hear from you (publicly or privately).
> I want to be sure to identify all the major stakeholders. I would
> also like to hear your plans for getting your code into the tree... :-)
I'm the author of a driver for the No Wires Needed card family.
It's a bit of an odd-man-out in the wireless devices world, as all the
wireless management is being done in firmware. Packets are read/sent
through a 16550 type interface as ethernet packets, and management
packets to control the card are sent in a similar way (but with a
different packet type). I inject management packets into the network
queue with dev_queue_xmit(), meaning the network queue takes care of the
correct locking.
I'd be interested in getting it integrated into mainline, although I'll
have to devote some time to get the pcmcia handling up to scratch, as
well as update to the latest wireless extensions (or any of the other
management utensils).
Let me know if you are interested in a patch, and I'll see what I can do
in the near future.
--
Bas Vermeulen <[email protected]>
John W. Linville wrote:
> If you are the maintainer of an out-of-tree driver or other component
> (e.g. softmac), please let me hear from you (publicly or privately).
> I want to be sure to identify all the major stakeholders. I would
> also like to hear your plans for getting your code into the tree... :-)
Thanks for stepping up for this role - I'm sure it will help the
situation improve. Here's some info about an out-of-tree driver for you:
ZD1211.
These are USB 2.0 wireless adapters, there are about 20 available on the
market, all branded differently.
There is a GPL driver available from ZyDAS (the manufacturer) but, well,
you really don't want to see it. There have been projects come and go
(zd1211.sf.net, zd1211.ath.cx) which try to make the ZyDAS driver more
workable, but they restrict themselves to small unobtrusive patches,
leaving the code still in a horrific state, not at all suited for kernel
inclusion.
ZyDAS also made the device specs available to us, however they are
somewhat inaccurate, almost as if they were written about another device
altogether.
Myself and two others have recently started rewriting the driver:
http://zd1211.ath.cx/wiki/RoadmapForKernelInclusion
We're in very early stages but progress should be fairly quick once we
have 'deciphered' more of the junk in the vendor driver.
Right now we will be using the ieee80211 wireless stack, for the simple
reason that this is what is included in the kernel, and our top priority
is inclusion ASAP.
FWIW, my opinion is that the devicescape code should be broken down and
used to extend the existing stack, no matter how 'good' it is. The way
it has been developed (i.e. totally outside of the ieee80211 stack) is
somewhat insulting to our development process.
Daniel
Daniel Drake wrote:
> FWIW, my opinion is that the devicescape code should be broken down and
> used to extend the existing stack, no matter how 'good' it is. The way
> it has been developed (i.e. totally outside of the ieee80211 stack) is
> somewhat insulting to our development process.
Strongly agreed, though perhaps some of the blame rests on me for
letting ieee80211 sit around too long without a clear maintainer...
Jeff
Hi!
> > Like the OSS/Alsa or XFree3.x/XFree4.x situations.
>
> And OSS/ALSA is an example why this is not a good thing:
> - OSS in the kernel is unmaintained
> - people forced to use OSS drivers can't use applications only
> supporting ALSA
Well, it is different. Current ieee80211 stack is going to be
maintained by Intel -- because they need it for their hw.
And it will be very easy to find maintainer for the new stack...
So we already have two-stack situation here.
--
Thanks, Sharp!
On Wed, Jan 11, 2006 at 08:37:32PM +0000, Pavel Machek wrote:
> Hi!
>
> > > Like the OSS/Alsa or XFree3.x/XFree4.x situations.
> >
> > And OSS/ALSA is an example why this is not a good thing:
> > - OSS in the kernel is unmaintained
> > - people forced to use OSS drivers can't use applications only
> > supporting ALSA
>
> Well, it is different. Current ieee80211 stack is going to be
> maintained by Intel -- because they need it for their hw.
> And it will be very easy to find maintainer for the new stack...
>
> So we already have two-stack situation here.
No, ieee80211 has always been intended for use by all drivers.
Read the archives... there have been a few efforts to start merging
HostAP and ieee80211 code, and further efforts exist out of tree that
add softmac support.
Remember Linux's maxim: do what you must, and no more.
That implies that new users SHOULD update ieee80211 for their needs.
Jeff