Mailing List Archive: Linux: Kernel

Broadcom 43xx first results

1 2 3

View All

Index | Next | Previous | View Threaded

mbuesch at freenet

Dec 4, 2005, 10:50 AM

Post #1 of 62 (6144 views)
Permalink

Broadcom 43xx first results

Hi,

I am a developer of the Broadcom-43xx driver project.
(The 43xx chipset is used in a lot of chipsets, including
the Apple Airport 2 card).

I am writing this mail on my PowerBook and it is sent
wireless to my AP.
That means, we can transmit real data, if you did not get it, yet. :)

That does _not_ mean, that it completely works, yet.
The team is in the progress of writing a SoftwareMAC layer,
which is needed for the bcm device. The SoftMAC is still very
incomplete. So do not expect to do any fancy stuff like WPA
or something line that with it.
Please be patient, thanks. :)

If you want to try the driver, a few steps have to be done manually,
because the SoftMAC doesn't do them automatically, yet:

insmod ieee80211softmac.ko
insmod bcm430x.ko
ifup ethX
iwconfig ethX channel YOUR_AP_CHANNEL
iwconfig ethX essid ESSID_OF_YOUR_AP
In between you should pray from time to time.

If it works without crashes, cool. :)
If it crashes, well, fix it or send us a complete OOPS message
including detailed information about the device. Most information
about the device is printed on insmod. Including this information is
_important_, because there are so many different devices around.

Do _not_ expect to get any 802.11a based device working, yet. Only b/g
devices should "work".

BCM43xx driver:
http://bcm43xx.berlios.de
Required SoftMAC Layer:
http://softmac.sipsolutions.net

Have fun.

"Jetzt Handykosten senken mit klarmobil - 15 Ct./Min.! Hier klicken"
www.klarmobil.de/index.html?pid=73025

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

feyd at seznam

Dec 4, 2005, 11:52 AM

Post #2 of 62 (6069 views)
Permalink

Re: [Bcm43xx-dev] Broadcom 43xx first results [In reply to]

On Sun, 04 Dec 2005 19:50:08 +0100 (CET)
mbuesch[at]freenet.de wrote:

> I am writing this mail on my PowerBook and it is sent
> wireless to my AP.
> That means, we can transmit real data, if you did not get it, yet. :)

Amazing progress :)

> That does _not_ mean, that it completely works, yet.
> The team is in the progress of writing a SoftwareMAC layer,
> which is needed for the bcm device. The SoftMAC is still very
> incomplete. So do not expect to do any fancy stuff like WPA
> or something line that with it.
> Please be patient, thanks. :)

Why not use the new in-kernel wifi stack?

Feyd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

mbuesch at freenet

Dec 4, 2005, 11:58 AM

Post #3 of 62 (6047 views)
Permalink

Re: [Bcm43xx-dev] Broadcom 43xx first results [In reply to]

On Sunday 04 December 2005 20:52, you wrote:
> On Sun, 04 Dec 2005 19:50:08 +0100 (CET)
> mbuesch[at]freenet.de wrote:
>
> > I am writing this mail on my PowerBook and it is sent
> > wireless to my AP.
> > That means, we can transmit real data, if you did not get it, yet. :)
>
> Amazing progress :)
>
> > That does _not_ mean, that it completely works, yet.
> > The team is in the progress of writing a SoftwareMAC layer,
> > which is needed for the bcm device. The SoftMAC is still very
> > incomplete. So do not expect to do any fancy stuff like WPA
> > or something line that with it.
> > Please be patient, thanks. :)
>
> Why not use the new in-kernel wifi stack?

We do. The SoftMAC is an extension to it.
SoftMAC = Software Medium Access Control. It is about sending
and receiving management frames.
Some chips do this in hardware, so it is not part of the ieee80211 stack.
(the ipw2x00 do it in hardware, for example.)

PS: Sorry for the spam on the bottom of the previous mail. I had
to send it with the web-interface.

--
Greetings Michael.

jkmaline at cc

Dec 4, 2005, 9:50 PM

Post #4 of 62 (6048 views)
Permalink

Re: [Bcm43xx-dev] Broadcom 43xx first results [In reply to]

On Sun, Dec 04, 2005 at 08:58:30PM +0100, Michael Buesch wrote:

> > Why not use the new in-kernel wifi stack?
>
> We do. The SoftMAC is an extension to it.
> SoftMAC = Software Medium Access Control. It is about sending
> and receiving management frames.
> Some chips do this in hardware, so it is not part of the ieee80211 stack.
> (the ipw2x00 do it in hardware, for example.)

Wouldn't it be better to try to get that functionality added into the
net/ieee80211 code instead of maintaining separate extension outside the
kernel tree? Many modern cards need the ability for the host CPU to take
care of management frame sending and receiving and from my view point,
this code should be in net/ieee80211. Many (all?) of the functions in
this "SoftMAC" look like something that would be nice to have as an
option in net/ieee80211. In other words, the low-level driver would
indicate what kind of functionality it needs and ieee80211 stack would
behave differently based on the underlying hardware profile.

ipw2x00 happens to be one of the main users of net/ieee80211 at the
moment, but it is by no means the only one and it should not be
defining what kind of functionality ends up being included in
net/ieee80211.

--
Jouni Malinen PGP id EFC895FA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

benh at kernel

Dec 4, 2005, 10:05 PM

Post #5 of 62 (6051 views)
Permalink

Re: [Bcm43xx-dev] Broadcom 43xx first results [In reply to]

> Wouldn't it be better to try to get that functionality added into the
> net/ieee80211 code instead of maintaining separate extension outside the
> kernel tree? Many modern cards need the ability for the host CPU to take
> care of management frame sending and receiving and from my view point,
> this code should be in net/ieee80211. Many (all?) of the functions in
> this "SoftMAC" look like something that would be nice to have as an
> option in net/ieee80211. In other words, the low-level driver would
> indicate what kind of functionality it needs and ieee80211 stack would
> behave differently based on the underlying hardware profile.

It would certainly be a good idea and I'm sure that's what will happen
once the code is mature enough ;)

Ben.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

mbuesch at freenet

Dec 5, 2005, 3:08 AM

Post #6 of 62 (6039 views)
Permalink

Re: [Bcm43xx-dev] Broadcom 43xx first results [In reply to]

On Monday 05 December 2005 06:50, you wrote:
> On Sun, Dec 04, 2005 at 08:58:30PM +0100, Michael Buesch wrote:
>
> > > Why not use the new in-kernel wifi stack?
> >
> > We do. The SoftMAC is an extension to it.
> > SoftMAC = Software Medium Access Control. It is about sending
> > and receiving management frames.
> > Some chips do this in hardware, so it is not part of the ieee80211 stack.
> > (the ipw2x00 do it in hardware, for example.)
>
> Wouldn't it be better to try to get that functionality added into the
> net/ieee80211 code instead of maintaining separate extension outside the
> kernel tree? Many modern cards need the ability for the host CPU to take
> care of management frame sending and receiving and from my view point,
> this code should be in net/ieee80211. Many (all?) of the functions in
> this "SoftMAC" look like something that would be nice to have as an
> option in net/ieee80211. In other words, the low-level driver would
> indicate what kind of functionality it needs and ieee80211 stack would
> behave differently based on the underlying hardware profile.
>
> ipw2x00 happens to be one of the main users of net/ieee80211 at the
> moment, but it is by no means the only one and it should not be
> defining what kind of functionality ends up being included in
> net/ieee80211.

The SoftMAC is a separate module. That is _good_, so devices like
the ipw do not have to load the code, because they do not need it.
The SoftMAC ties (and integrates) very close to the ieee80211 subsystem.

device <--> Driver <----------> ieee80211 <-----> kernel networking layer
| ^
| |
.--------> SoftMAC ---.

This is approximately how it works.
You see that SoftMAC is not exactly a part or the ieee80211 subsystem,
but it uses its interface to TX a frame (and the struct to get
some information about the device).
This works without any modifications to the ieee80211 layer and I
doubt big changes will have to be made in future.

In fact, we started with the SoftMAC layer integrated into the
ieee80211 subsystem. You can still find the patches on the project FTP.
We decided to drop it, because of the bad design.

This all works fine. There is absolutely no need to bloat the
ieee80211 layer with functionality, which is not needed by all devices.

--
Greetings Michael.

jkmaline at cc

Dec 5, 2005, 6:19 AM

Post #7 of 62 (6040 views)
Permalink

Re: [Bcm43xx-dev] Broadcom 43xx first results [In reply to]

On Mon, Dec 05, 2005 at 12:08:16PM +0100, Michael Buesch wrote:

> The SoftMAC is a separate module. That is _good_, so devices like
> the ipw do not have to load the code, because they do not need it.
> The SoftMAC ties (and integrates) very close to the ieee80211 subsystem.

I like the modular design..

> You see that SoftMAC is not exactly a part or the ieee80211 subsystem,
> but it uses its interface to TX a frame (and the struct to get
> some information about the device).

.. but I disagree with this. If there is functionality like generating
management frames, it is very much part of the ieee80211 subsystem in my
opinion.

> This all works fine. There is absolutely no need to bloat the
> ieee80211 layer with functionality, which is not needed by all devices.

I'm afraid of this leading to duplicated work since ieee80211 stack is
being used without this new SoftMAC code for devices that do need host
CPU to take care of functionality that is currently in SoftMAC module
and will be added to ieee80211 subsystem.

--
Jouni Malinen PGP id EFC895FA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

mbuesch at freenet

Dec 5, 2005, 6:28 AM

Post #8 of 62 (6046 views)
Permalink

Re: [Bcm43xx-dev] Broadcom 43xx first results [In reply to]

On Monday 05 December 2005 15:19, you wrote:
> On Mon, Dec 05, 2005 at 12:08:16PM +0100, Michael Buesch wrote:
>
> > The SoftMAC is a separate module. That is _good_, so devices like
> > the ipw do not have to load the code, because they do not need it.
> > The SoftMAC ties (and integrates) very close to the ieee80211 subsystem.
>
> I like the modular design..
>
> > You see that SoftMAC is not exactly a part or the ieee80211 subsystem,
> > but it uses its interface to TX a frame (and the struct to get
> > some information about the device).
>
> .. but I disagree with this. If there is functionality like generating
> management frames, it is very much part of the ieee80211 subsystem in my
> opinion.

Think of SoftMAC as an extension to ieee80211.

> > This all works fine. There is absolutely no need to bloat the
> > ieee80211 layer with functionality, which is not needed by all devices.
>
> I'm afraid of this leading to duplicated work since ieee80211 stack is
> being used without this new SoftMAC code for devices that do need host
> CPU to take care of functionality that is currently in SoftMAC module
> and will be added to ieee80211 subsystem.

Well, I do not care for drivers ignoring SoftMAC and duplicating
the work. The question is: Why don't these drivers use SoftMAC?
(Yeah, because it is incomplete, is the answer. :D I am talking
about future.)
What is so hard about a driver including ieee80211.h _and_
ieee80211softmac.h, if it requires Software MAC? And what
exactly is duplicated work here? SoftMAC does _not_ duplicate;
it extends.

--
Greetings Michael.

jkmaline at cc

Dec 5, 2005, 6:41 AM

Post #9 of 62 (6047 views)
Permalink

Re: [Bcm43xx-dev] Broadcom 43xx first results [In reply to]

On Mon, Dec 05, 2005 at 03:28:32PM +0100, Michael Buesch wrote:

> Well, I do not care for drivers ignoring SoftMAC and duplicating
> the work. The question is: Why don't these drivers use SoftMAC?
> (Yeah, because it is incomplete, is the answer. :D I am talking
> about future.)

For me, the answer would have been because I had no idea about that
being worked on somewhere else. Now the answer would be more likely
"because it is not in netdev-2.6 tree with rest of ieee80211
development".

> What is so hard about a driver including ieee80211.h _and_
> ieee80211softmac.h, if it requires Software MAC? And what
> exactly is duplicated work here? SoftMAC does _not_ duplicate;
> it extends.

That is not hard as long as this work is easily available.

--
Jouni Malinen PGP id EFC895FA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

jbenc at suse

Dec 5, 2005, 10:00 AM

Post #10 of 62 (6044 views)
Permalink

Re: Broadcom 43xx first results [In reply to]

On Sun, 04 Dec 2005 19:50:08 +0100, mbuesch[at]freenet.de wrote:
> The team is in the progress of writing a SoftwareMAC layer,
> which is needed for the bcm device. The SoftMAC is still very
> incomplete. So do not expect to do any fancy stuff like WPA
> or something line that with it.

Why yet another attempt to write 802.11 stack? Sure, the one currently
in the kernel is unusable and everybody knows about it. But why not to
improve code opensourced by Devicescape some time ago instead of
inventing the wheel again and again? Yes, I know that code is not
perfect and needs a lot of work, but it is the best piece of code we
have available now. And it _does_ support WPA and such - in fact, it is
nearly complete.

Please take a look at http://kernel.org/pub/linux/kernel/people/jbenc/

Thanks,

--
Jiri Benc
SUSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

netdev at nospam

Dec 5, 2005, 10:14 AM

Post #11 of 62 (6034 views)
Permalink

Re: Broadcom 43xx first results [In reply to]

Hi.

On Mon, 2005-12-05 at 19:00 +0100, Jiri Benc wrote:
> Why yet another attempt to write 802.11 stack? Sure, the one currently
> in the kernel is unusable and everybody knows about it. But why not to
> improve code opensourced by Devicescape some time ago instead of
> inventing the wheel again and again?

Or, in case there is some unknown objection to the mentioned code: use
the 802.11 stack that comes along with MadWifi, which provides things
like virtual interfaces (for multiple SSID support on one physical card)
and WPA support.

Although I'm a bit biased towards MadWifi, I'd second your suggestion to
make use of the Devicescape code. The benefit of having a fully-blown
802.11 stack in the kernel that drivers can make use of has been
discussed before, so I won't go into that yet again.

Bye, Mike

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

shemminger at osdl

Dec 5, 2005, 10:24 AM

Post #12 of 62 (6041 views)
Permalink

Re: Broadcom 43xx first results [In reply to]

On Mon, 05 Dec 2005 19:14:03 +0100
Michael Renzmann <netdev[at]nospam.otaku42.de> wrote:

> Hi.
>
> On Mon, 2005-12-05 at 19:00 +0100, Jiri Benc wrote:
> > Why yet another attempt to write 802.11 stack? Sure, the one currently
> > in the kernel is unusable and everybody knows about it. But why not to
> > improve code opensourced by Devicescape some time ago instead of
> > inventing the wheel again and again?
>
> Or, in case there is some unknown objection to the mentioned code: use
> the 802.11 stack that comes along with MadWifi, which provides things
> like virtual interfaces (for multiple SSID support on one physical card)
> and WPA support.
>
> Although I'm a bit biased towards MadWifi, I'd second your suggestion to
> make use of the Devicescape code. The benefit of having a fully-blown
> 802.11 stack in the kernel that drivers can make use of has been
> discussed before, so I won't go into that yet again.
>

Please use or extend the existing net/ieee80211 stack in 2.6.
The defacto plan is to convert all wifi drivers that need software
support to use that.

--
Stephen Hemminger <shemminger[at]osdl.org>
OSDL http://developer.osdl.org/~shemminger
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

josejx at gentoo

Dec 5, 2005, 10:38 AM

Post #13 of 62 (6053 views)
Permalink

Re: Broadcom 43xx first results [In reply to]

> Why yet another attempt to write 802.11 stack? Sure, the one currently
> in the kernel is unusable and everybody knows about it. But why not to
> improve code opensourced by Devicescape some time ago instead of
> inventing the wheel again and again? Yes, I know that code is not
> perfect and needs a lot of work, but it is the best piece of code we
> have available now. And it _does_ support WPA and such - in fact, it
> is nearly complete.
>
> Please take a look at http://kernel.org/pub/linux/kernel/people/jbenc/

We're not writing an entire stack. We're writing a layer that sits in
between the current ieee80211 stack that's already present in the kernel
and drivers that do not have a hardware MAC. Since ieee80211 is already
in use in the kernel today, this seemed like a natural and useful
extension to the existing code. I agree that it's somewhat wasteful to
keep rewriting 802.11 stacks and we considered other options, but it
seemed like a more logical choice to work with what was available and
recommended than to use an external stack.

-Joe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

jgarzik at pobox

Dec 5, 2005, 10:46 AM

Post #14 of 62 (6042 views)
Permalink

Re: Broadcom 43xx first results [In reply to]

Michael Renzmann wrote:
> Hi.
>
> On Mon, 2005-12-05 at 19:00 +0100, Jiri Benc wrote:
>
>>Why yet another attempt to write 802.11 stack? Sure, the one currently
>>in the kernel is unusable and everybody knows about it. But why not to
>>improve code opensourced by Devicescape some time ago instead of
>>inventing the wheel again and again?
>
>
> Or, in case there is some unknown objection to the mentioned code: use
> the 802.11 stack that comes along with MadWifi, which provides things
> like virtual interfaces (for multiple SSID support on one physical card)
> and WPA support.
>
> Although I'm a bit biased towards MadWifi, I'd second your suggestion to
> make use of the Devicescape code. The benefit of having a fully-blown
> 802.11 stack in the kernel that drivers can make use of has been
> discussed before, so I won't go into that yet again.

Use the stack that's already in the kernel.

Encouraging otherwise hinders continued wireless progress under Linux.

Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

jbenc at suse

Dec 5, 2005, 10:49 AM

Post #15 of 62 (6048 views)
Permalink

Re: Broadcom 43xx first results [In reply to]

On Mon, 05 Dec 2005 13:46:43 -0500, Jeff Garzik wrote:
> Use the stack that's already in the kernel.
>
> Encouraging otherwise hinders continued wireless progress under Linux.

There is nothing like a "802.11 stack" currently in the kernel,
regardless what James Ketrenos is saying. Sorry.

--
Jiri Benc
SUSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

jgarzik at pobox

Dec 5, 2005, 10:52 AM

Post #16 of 62 (6039 views)
Permalink

Re: [Bcm43xx-dev] Broadcom 43xx first results [In reply to]

In general, Jouni's points are good, as are Michael's.

The key question is about the size of the SoftMAC code. If its huge, an
ieee80211 sub-module makes sense. If it's not, then adding the code to
net/ieee80211 makes a lot more sense.

Certainly some chips will use more ieee80211 code than others. This is
no different than ethernet NICs: some make use of TSO and checksum
offload code included in every kernel, while for other NICs the kernel
TSO/csum code is just dead weight.

In general, adding directly to net/ieee80211 is preferred, UNLESS there
are overriding reasons not to do so (such as a huge size increase).

Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

jgarzik at pobox

Dec 5, 2005, 10:54 AM

Post #17 of 62 (6041 views)
Permalink

Re: Broadcom 43xx first results [In reply to]

Jiri Benc wrote:
> On Mon, 05 Dec 2005 13:46:43 -0500, Jeff Garzik wrote:
>
>>Use the stack that's already in the kernel.
>>
>>Encouraging otherwise hinders continued wireless progress under Linux.

> There is nothing like a "802.11 stack" currently in the kernel,
> regardless what James Ketrenos is saying. Sorry.

Complete bullshit. There is obviously 802.11 generic code in the
kernel, and that's what _I_ am saying, because it's true.

If it doesn't support your favorite wireless chipset, then submit patches.

Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

jbenc at suse

Dec 5, 2005, 10:55 AM

Post #18 of 62 (6045 views)
Permalink

Re: Broadcom 43xx first results [In reply to]

On Mon, 05 Dec 2005 13:38:37 -0500, Joseph Jezak wrote:
> We're not writing an entire stack. We're writing a layer that sits in
> between the current ieee80211 stack that's already present in the kernel
> and drivers that do not have a hardware MAC. Since ieee80211 is already
> in use in the kernel today, this seemed like a natural and useful
> extension to the existing code. I agree that it's somewhat wasteful to
> keep rewriting 802.11 stacks and we considered other options, but it
> seemed like a more logical choice to work with what was available and
> recommended than to use an external stack.

Unfortunately, the only long-term solution is to rewrite completely the
current in-kernel ieee80211 code (I would not call it a "stack") or
replace it with something another. The current code was written for
Intel devices and it doesn't support anything else - so every developer
of a wifi driver tries to implement his own "softmac" now. I cannot see
how this can move as forward and I think we can agree this is not the
way to go.

Rewriting (or, if you like, enhancing) the current 802.11 code seems to
be wasting of time now, when nearly complete Linux stack was opensourced
by Devicescape. We can try to merge it, but I'm not convinced it is
possible, the Devicescape's stack is far more advanced.

--
Jiri Benc
SUSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

jgarzik at pobox

Dec 5, 2005, 11:08 AM

Post #19 of 62 (6039 views)
Permalink

Re: Broadcom 43xx first results [In reply to]

Jiri Benc wrote:
> On Mon, 05 Dec 2005 13:38:37 -0500, Joseph Jezak wrote:
>
>>We're not writing an entire stack. We're writing a layer that sits in
>>between the current ieee80211 stack that's already present in the kernel
>>and drivers that do not have a hardware MAC. Since ieee80211 is already
>>in use in the kernel today, this seemed like a natural and useful
>>extension to the existing code. I agree that it's somewhat wasteful to
>>keep rewriting 802.11 stacks and we considered other options, but it
>>seemed like a more logical choice to work with what was available and
>>recommended than to use an external stack.
>
>
> Unfortunately, the only long-term solution is to rewrite completely the
> current in-kernel ieee80211 code (I would not call it a "stack") or
> replace it with something another. The current code was written for
> Intel devices and it doesn't support anything else - so every developer

Patently false.

ieee80211 is used by Intel. Some bits used by HostAP, which also
duplicates a lot of ieee80211 code. And bcm43xx. And another couple
drivers found in -mm or out-of-tree.

> of a wifi driver tries to implement his own "softmac" now. I cannot see
> how this can move as forward and I think we can agree this is not the
> way to go.

You're agreeing with only yourself, then?

> Rewriting (or, if you like, enhancing) the current 802.11 code seems to
> be wasting of time now, when nearly complete Linux stack was opensourced
> by Devicescape. We can try to merge it, but I'm not convinced it is
> possible, the Devicescape's stack is far more advanced.

This invalid logic is why we have a ton of wireless stacks, all
duplicating each other.

Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

hch at infradead

Dec 5, 2005, 11:10 AM

Post #20 of 62 (6047 views)
Permalink

Re: Broadcom 43xx first results [In reply to]

On Mon, Dec 05, 2005 at 07:55:43PM +0100, Jiri Benc wrote:
> Unfortunately, the only long-term solution is to rewrite completely the
> current in-kernel ieee80211 code (I would not call it a "stack") or
> replace it with something another. The current code was written for
> Intel devices and it doesn't support anything else - so every developer
> of a wifi driver tries to implement his own "softmac" now. I cannot see
> how this can move as forward and I think we can agree this is not the
> way to go.

Please stop beeing a freaking jackass. There are various projects using
the current code. It's not perfect but people are working on it. And Joseph &
friends are writing a module to support softmac cards in that framework,
which is one of the most urgently needed things right now, because all the
existing softmac frameworks don't work with that code.

And please stop your stupid devicespace advertisements. If you think the
code is so useful why don't you send patches to integrate it with the
currently existing wireless code (after cleaning up the horrible mess
it is currently)?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

jbenc at suse

Dec 5, 2005, 11:11 AM

Post #21 of 62 (6046 views)
Permalink

Re: Broadcom 43xx first results [In reply to]

On Mon, 05 Dec 2005 13:54:00 -0500, Jeff Garzik wrote:
> Complete bullshit. There is obviously 802.11 generic code in the
> kernel, and that's what _I_ am saying, because it's true.
>
> If it doesn't support your favorite wireless chipset, then submit patches.

I have no favorite chipset. I read tons of source code of different
drivers instead. Current 802.11 code supports no management stuff at
all. And nearly every driver needs support for it - ask any developer of
wireless driver except James Ketrenos (oh, wait a moment - although ipw
devices do, unlike other devices, a lot of work in firmware, he is
implementing in the driver some management stuff too - strange, is not
his own "stack" good enough even for himself?).

And, as you might notice, I sent many patches. Only minor ones were
accepted. And then I started (and attended) a debate among wireless
developers about concepts of 802.11 stack, do you remember? And it gave
us interesting results. That results were implemented (patches were sent
and not accepted).

It may appears that I stopped afterwards, but it is not true. Nearly
after that debate had finished, Jouni announced opensourcing of the
stack he has been working on for several years. From that time I have
been trying to get familiar with that stack, it is quite complex. I have
one semi-working driver for it now and I think I know about issues of
the stack.

--
Jiri Benc
SUSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

jbenc at suse

Dec 5, 2005, 11:18 AM

Post #22 of 62 (6045 views)
Permalink

Re: Broadcom 43xx first results [In reply to]

On Mon, 05 Dec 2005 14:08:28 -0500, Jeff Garzik wrote:
> Patently false.
>
> ieee80211 is used by Intel. Some bits used by HostAP, which also
> duplicates a lot of ieee80211 code. And bcm43xx. And another couple
> drivers found in -mm or out-of-tree.

Hostap uses only encryption code, which was copied from - guess who -
hostap. Everything other must be done by the hostap driver itself.

bcm43xx can use - like every other driver - only constants and defines
from ieee80211.h. This is the reason why they are trying to implement
"softmac" on top of it. But that work was already done by Jouni.

> > of a wifi driver tries to implement his own "softmac" now. I cannot see
> > how this can move as forward and I think we can agree this is not the
> > way to go.
>
> You're agreeing with only yourself, then?

I meant that every driver tries to implements its own "softmac". This is
not the way to go, right?

> > Rewriting (or, if you like, enhancing) the current 802.11 code seems to
> > be wasting of time now, when nearly complete Linux stack was opensourced
> > by Devicescape. We can try to merge it, but I'm not convinced it is
> > possible, the Devicescape's stack is far more advanced.
>
> This invalid logic is why we have a ton of wireless stacks, all
> duplicating each other.

Heh? We have one nearly finished stack (and no, it's not the one in
kernel). Why should we try to implement a new stack instead of fixing
some issues of the nearly finished one?

--
Jiri Benc
SUSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

hch at infradead

Dec 5, 2005, 11:20 AM

Post #23 of 62 (6042 views)
Permalink

Re: [Bcm43xx-dev] Broadcom 43xx first results [In reply to]

On Mon, Dec 05, 2005 at 01:52:21PM -0500, Jeff Garzik wrote:
> In general, Jouni's points are good, as are Michael's.
>
> The key question is about the size of the SoftMAC code. If its huge, an
> ieee80211 sub-module makes sense. If it's not, then adding the code to
> net/ieee80211 makes a lot more sense.
>
> Certainly some chips will use more ieee80211 code than others. This is
> no different than ethernet NICs: some make use of TSO and checksum
> offload code included in every kernel, while for other NICs the kernel
> TSO/csum code is just dead weight.
>
> In general, adding directly to net/ieee80211 is preferred, UNLESS there
> are overriding reasons not to do so (such as a huge size increase).

I tend to disagree a bit here. If it can be separate without making the
API more complicated a separate module is nicer, if the API would get nasty
integerating it is better. And nevermind whether it's a separate module or
not it should live in net/ieee80211/ ;-)

In either case ?I think this decision is better left until the code is in
an almost mergeable shape, because then the details will be clear.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

jbenc at suse

Dec 5, 2005, 11:31 AM

Post #24 of 62 (6046 views)
Permalink

Re: Broadcom 43xx first results [In reply to]

On Mon, 5 Dec 2005 19:10:08 +0000, Christoph Hellwig wrote:
> Please stop beeing a freaking jackass. There are various projects using
> the current code. It's not perfect but people are working on it.

Yes, and everyone implements his own softmac (this is the third one I
know about). I tried to put all of these efforts together (google
through the netdev archives) and wrote many patches.

> And Joseph &
> friends are writing a module to support softmac cards in that framework,
> which is one of the most urgently needed things right now, because all the
> existing softmac frameworks don't work with that code.

And authors of rtl8180 did it too. And authors of adm8211 too.

> And please stop your stupid devicespace advertisements. If you think the
> code is so useful why don't you send patches to integrate it with the
> currently existing wireless code (after cleaning up the horrible mess
> it is currently)?

This is what I'm doing last two months. But it's not so easy to clean it
up and it seems that nobody else is interested. But it has all of the
features you need (except active scanning) - this is the reason I
stopped to work on improving current in-kernel 802.11 code and focused
on Devicescape's code. It is several years beyond the state that current
code is at now. And it is not an advertisement, it is a fact.

--
Jiri Benc
SUSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

pavel at ucw

Dec 5, 2005, 11:40 AM

Post #25 of 62 (6045 views)
Permalink

Re: Broadcom 43xx first results [In reply to]

Hi!

> I am a developer of the Broadcom-43xx driver project.
> (The 43xx chipset is used in a lot of chipsets, including
> the Apple Airport 2 card).
>
> I am writing this mail on my PowerBook and it is sent
> wireless to my AP.
> That means, we can transmit real data, if you did not get it,
> yet. :)

Congratulations ;-). I have bcm4303 here:

0000:00:0c.0 Network controller: Broadcom Corporation BCM4306
802.11b/g Wireless LAN Controller (rev 03)

...

> If it works without crashes, cool. :)
> If it crashes, well, fix it or send us a complete OOPS message
> including detailed information about the device. Most information
> about the device is printed on insmod. Including this information is
> _important_, because there are so many different devices around.
>
> Do _not_ expect to get any 802.11a based device working, yet. Only b/g
> devices should "work".
>
> BCM43xx driver:
> http://bcm43xx.berlios.de
> Required SoftMAC Layer:
> http://softmac.sipsolutions.net

...but don't feel like playing with *two* different revision control
systems just to get the sources. Do you think you could just mail the
diffs to the list?
Pavel
--
Thanks, Sharp!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

1 2 3

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com