|| ||"John W. Linville" <email@example.com>|
|| ||wireless: the contenders|
|| ||Wed, 18 Jan 2006 15:06:20 -0500|
|| ||firstname.lastname@example.org, email@example.com,
First, the news everyone will like. Thanks to the kernel.org team
I now have a place to publish a wireless tree:
The tree there has a number of branches, so many that you need
The "master" branch of that tree is (mostly) up-to-date w/ Linus, plus
changes I recently sent to Jeff. Those changes are also available on
the "upstream-jgarzik" branch, but it is frozen to when I requested
The tree also has "softmac" and "dscape" branches. The "softmac"
branch includes the Johannes Berg softmac code as well as the the
BCM43xx driver based upon that code. The "dscape" branch includes
the DeviceScape patches from Jiri Benc as well as the BCM43xx driver
ported to the DeviceScape stack.
The fact that the BCM43xx team has ported their driver to both stacks
provides us an excellent opportunity for some objective, "apples to
apples" comparisons between the major stacks. I would like to take
this opportunity to thank them for taking the trouble to do that work
and to make both versions available for comparison.
BTW, those trying to actually use the dscape code will want to poke
around Jiri's kernel.org directories:
Jiri has some information there that will likely be useful to you.
The other branches are for administrative purposes, and can mostly
Along with bugfixes and enhancements to the current code (which will
be targeting the "master" branch), I would like to see driver and
stack patches for both the "softmac" and "dscape" branches. I would
like to see what is really out there before making a final call on
which stack to adopt permanently.
If you have an out-of-tree driver which targets either (or both)
stacks, please send patches. If you are working on porting an
in-kernel driver to one of these stacks (either from the other stack
or from its private stack), please send patches. If you have fixes
or enhancements pending for either of these stacks, then please
Don't waste any time with your patches. There is good reason to make
a decision quickly, and plenty of pressure to do so. Your code could
be a significant factor in making that decision.
I know that many of you believe that this approach is a bad idea,
for a variety of reasons. I find those arguments valid, and
even persuasive. The point of this exercise is NOT to push two
stacks forward into Linus' kernel. The point is to catalog the
true state of affairs and to collect as large a wireless driver
codebase as possible. You might think of this as a Domesday Book
(http://en.wikipedia.org/wiki/Domesday_Book) for Linux wireless.
Hopefully the act of collecting these patches will also allow the less
motivated among us to have a chance to evaluate the stacks involved.
There are bound to be some wise and skilled kernel hackers out there
that are just a little too busy to track-down all these patches
I appreciate all the commentary and ideas expressed over the past
couple of weeks. I also think the driver writers are doing a good
job with what they've been given so far. I hope this helps to bring
the driver guys in out of the cold, and to put some weight behind
the discussions of where we need to go.
John W. Linville