Mailing List Archive: Linux: Kernel

Broadcom 43xx first results

1 2 3

View All

Index | Next | Previous | View Threaded

laforge at gnumonks

Dec 6, 2005, 11:16 PM

Post #51 of 62 (2873 views)
Permalink

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

On Tue, Dec 06, 2005 at 02:05:07PM -0500, Jeff Garzik wrote:
> Harald Welte wrote:
> >I also think that there is a lack of knowledge on the architecture of
> >802.11 low-level protocols and drivers among many people (including
> >myself) in the network community. Only this way I can explain why there
> >are always people who claim that the kernel already has a 802.11
> >'stack'.
>
> This last sentence, regardless of the source, is simply playing with words.

I don't think that having clear definitions of certain terms is playing
with words. I don't neccessarily care which words are used, but it's
always useful to have common, well-defined terminology.

I also wouldn't call the TCP code a stack, if it hadn't all the state
engine in it.

> We have 802.11 common code in the kernel, that several drivers are
> using.

Yes.

> Future drivers should modify that common code to suit their
> needs, rather than dropping it and starting from scratch.

I did not state that it has to be replaced. I'm much in favour of
gradual changes myself.

--
- Harald Welte <laforge [at] gnumonks> http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)

mbuesch at freenet

Dec 7, 2005, 5:34 AM

Post #52 of 62 (2872 views)
Permalink

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

On Wednesday 07 December 2005 00:19, you wrote:
> From: Harald Welte <laforge [at] gnumonks>
> Date: Tue, 6 Dec 2005 20:40:47 +0530
>
> > I'm also in favor of merging the devicescape code, but I don't see it
> > happening without somebody taking care to provide all the required
> > levels of interfaces (I see at least three levels of API's that a wireless
> > driver would need, depending on how much stuff is done in
> > hardware/firmware and how much in software.
>
> I hate to say this, but part of the problem is exactly the fact
> that all the implementors have implemented different levels of
> hardware-MAC'ness in their wireless products.
>
> Stated even further, things might have been more consistent if M$ had
> specified a set of driver interfaces into their own softmac stack,
> which I am to understand they are working on now.
>
> So every M$ wireless driver essentially links in their own softmac
> stack, if needed.
>
> This has resulted in a complicated situation for an already
> complicated technology. Therefore, the fact that it's taking this
> long to accomodate all of the cases in the vanilla tree is quite
> understandable.
>
> I'm at the point where I frankly don't care which softmac
> implementation we go with, but rather I'm more concerned that we pick
> _ONE_ and just stick with it, and then adding the necessary interfaces
> and infrastructure as different wireless devices require.
>
> Yes, you hear me right, it's more important to agree to one
> implementation as the basis, even if it's the worst one currently.
> Division of labor is something we simply cannot afford on the wireless
> stack at this time.

I agree with you, and that is exactly what we are doing:
We take the existing code and add functionality to it. If the
added functionality is an external module, well, consinder this
as an extra cookie for devices which do not need MAC handling.

--
Greetings Michael.

jt at hpl

Dec 7, 2005, 11:05 AM

Post #53 of 62 (2865 views)
Permalink

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

On Tue, Dec 06, 2005 at 02:47:28PM -0800, jt wrote:
>
> MadWifi stack :
> drivers using it : MadWifi (non GPL)
> drivers in progress : FreeHAL Atheros, Prism54 softMAC, ural-ralink

Sam kindly pointed out that my statement above may be
confusing. It should read :

MadWifi stack :
drivers using it : Atheros (binary blob)
drivers in progress : FreeHAL Atheros, Prism54 softMAC, ural-ralink

Accept my apologies for the error.

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

jt at hpl

Dec 7, 2005, 11:16 AM

Post #54 of 62 (2877 views)
Permalink

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

On Tue, Dec 06, 2005 at 11:11:02PM -0800, Jouni Malinen wrote:
> On Tue, Dec 06, 2005 at 02:47:28PM -0800, Jean Tourrilhes wrote:
>
> > DeviceScape stack :
> > drivers using it : ?
> > potential drivers : hostap, ipw2100, ipw2200, r8180, adm8211
>
> It's mainly used with Atheros chipsets nowadays, but it has been used
> with couple of other chipsets, too, including Prism2/2.5/3 and parts of
> Host AP driver.

Well, the burning question is : Is it possible to include your
Atheros driver in the Linux kernel ? Meaning, will it be released, and
will it contain a binary blob ?
If we can't put it in the kernel, it does not bring any thing
new comapre to MadWifi.

> > If you want to use the DeviceScape stack instead of the IPW
> > stack, my first question is how do you plan to migrate the drivers
> > using it to the new stack. Currently, people are hard at work
> > targetting the IPW stack (see above), I don't want them to have to
> > throw away all their work.
>
> No matter how this is done, I think it is quite likely that lot of work
> has to be thrown away in the sense that it does not end up being in the
> kernel. Having n+1 implementations for generic 802.11 functionality is a
> good proof of this already being the case. I wouldn't say all work is
> thrown away, though, even if lots of code will get thrown away. It is
> good to get understanding on what kind of specific requirements each
> chipset has in order to be able to accommodate them in the 802.11 design
> for Linux.

Precisely, which is why I've been pushing as many driver as I
can in the kernel, so that the need is clear and obvious.

> Devicescape code is not actually derived from Host AP code. The user
> space component is same (hostapd), but the kernel side is completely new
> implementation. As far as IPW is concerned, some parts of it is indeed
> derived from Host AP (I can never remember which one, but either TX or
> RX; while the other side was new design for some reason).

Not cool. I usually don't like wrapper, but would it be
possible to wrap the IPW API around DeviceScape ?

> > Also, what puzzle me is that Jouni doesn't seem to have
> > anounced any plan to port his HostAP driver to his DeviceScape
> > stack. If there is one driver that should use it, that's HostAP.
>
> Prism2/2.5/3 is getting somewhat old nowadays and I certainly prefer
> other chipset designs that do not have a large firmware component
> preventing driver/802.11 stack from doing things. Anyway, I have
> actually used Devicescape code with Prism2/2.5/3 cards by taking the
> low-level parts of the Host AP driver. This just happened to be
> two-three years ago and that code has found no use after that, so it has
> not been maintained.

It's old, but because it's the only current card properly
supported under Linux, most people are still using it. And you have
many original Prism2 designs that you can't find with other chipset,
such as the high power version and the CF cards.

> I need to take a closer look at what could be done to merge the 802.11
> code in a way that would not break existing in-tree drivers that are
> using net/ieee80211 (i.e., mainly ipw2x00). I'm afraid quite large
> changes will be needed to make the current in-tree code more usable for
> devices that use very minimal firmware or no firmware at all. In
> addition, the issue of dropping AP code from Host AP when merging in the
> version that ipw2x00 was using needs more attention when deciding what
> kind of design would allow all drivers to work with shared IEEE 802.11
> stack.

Well, the problem is that the more we wait, the more people
are going in other directions. Driver authors are voting with their
feets. I personally welcome your contribution, and I must admit I
don't really know what is the best course of action.

> Jouni Malinen

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

jkmaline at cc

Dec 7, 2005, 11:47 AM

Post #55 of 62 (2856 views)
Permalink

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

On Wed, Dec 07, 2005 at 11:16:22AM -0800, Jean Tourrilhes wrote:

> Well, the burning question is : Is it possible to include your
> Atheros driver in the Linux kernel ? Meaning, will it be released, and
> will it contain a binary blob ?

If that were possible, it would have been released with the IEEE 802.11
code. It has the same issue as madwifi in the sense of depending on
Atheros hal code.

> Not cool. I usually don't like wrapper, but would it be
> possible to wrap the IPW API around DeviceScape ?

I would not even like to think about that.. ;-) I think we are in a
position where we are way more willing to change things than try to
maintain current interfaces in backwards compatible ways.

> > Prism2/2.5/3 is getting somewhat old nowadays and I certainly prefer

> It's old, but because it's the only current card properly
> supported under Linux, most people are still using it. And you have
> many original Prism2 designs that you can't find with other chipset,
> such as the high power version and the CF cards.

Agreed and as such, it is still on my list of things to maintain.
However, this certainly means that it is likely to be of lower priority
than some of the newer chipsets.

--
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
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

flamingice at sourmilk

Dec 7, 2005, 4:00 PM

Post #56 of 62 (2868 views)
Permalink

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

On Monday 05 December 2005 14:31, Jiri Benc wrote:
> > 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.
>
The softmac code that is still in adm8211 is actually based on an early
version of the softmac code that Jouni made for Devicescape. The Devicescape
code does much more useful stuff than the code currently in the kernel. Sure,
I can and have been porting adm8211 to the new kernel stuff.. but it already
works with a much more mature piece of softmac code. I see the use of Intel's
802.11 code as a step backwards.

-Michael Wu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
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 7, 2005, 5:05 PM

Post #57 of 62 (2884 views)
Permalink

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

Michael Wu wrote:
> The softmac code that is still in adm8211 is actually based on an early
> version of the softmac code that Jouni made for Devicescape. The Devicescape
> code does much more useful stuff than the code currently in the kernel. Sure,
> I can and have been porting adm8211 to the new kernel stuff.. but it already
> works with a much more mature piece of softmac code. I see the use of Intel's
> 802.11 code as a step backwards.

Then please update the code in the kernel.

Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
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 8, 2005, 3:32 AM

Post #58 of 62 (2876 views)
Permalink

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

On Wed, 7 Dec 2005 14:34:22 +0100, Michael Buesch wrote:
> I agree with you, and that is exactly what we are doing:
> We take the existing code and add functionality to it. If the
> added functionality is an external module, well, consinder this
> as an extra cookie for devices which do not need MAC handling.

I understand why you are trying to implement "softmac" as a separate
module. But please take a look at following:

1. Fragmentation. Almost every driver (the exception are devices which
do fragmentation in their firmware) needs to pass fragments to the
device one by one. To handle it effectively, you need fragments to be
passed to your hard_start_xmit sequentially (and not all at once). This
is of course solvable by a separate softmac module, if you implement it
as a layer between ieee80211 and a driver.

2. Devices capable to associate with multiple networks. Such a device
needs to be presented to userspace as several network devices. Again, it
is solvable by a separate softmac module, but you need softmac to be
something like a "proxy" for drivers (because you don't want to deal
with multiple net_devices in the driver).

3. WDS. This is nearly the same as above, but in addition you need a
different code for building 802.11 headers. So this will be built on top
of ieee80211 (because you want to use statistics gathering and so) but
at the same time you will have to reimplement the code responsible for
frame encapsulation in a softmac module. Or, you can add the support for
WDS directly to ieee80211, but then you will add the code for handling
of multiple devices there as well.

4. Access point mode. There is a lot of code needed for AP mode support.
It can be easily implemented in softmac module. But that code will be
used even by drivers for devices with complicated firmware (think about
communication with an userspace AP daemon which won't be easy and should
be consistent among drivers). So in the end (we want AP mode working for
all devices supporting it, don't we?) only a few drivers won't use
softmac module.

Those above are some reasons why I prefer complete 802.11 stack to be in
ieee80211 module. Maybe I'm wrong (and I will be more than happy to
advocate the separate softmac module if it turns out that I'm wrong),
but I'm thinking this way:

- If AP, WDS and so on is implemented in a softmac module, only a very
small amount of drivers won't use that module.

- Such softmac module needs to be implemented as a layer between
ieee80211 and a driver. This will lead to code duplication and will be
less effective.

- If AP, WDS and so on is implemented in ieee80211 module, softmac
module will be very tiny (especially compared to ieee80211 module) and
it is not worth effort to implement it as a separate module.

- (Not a strong argument) Most of drivers will use "softmac" anyway
(it's more than a half of drivers as somebody mentioned earlier).

Please, could you send your opinions to this issues and how to solve
them the best way? It seems that many people agree that separate softmac
module is the way to go, so I'm probably wrong with my conclusions.

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
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 8, 2005, 4:07 AM

Post #59 of 62 (2886 views)
Permalink

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

On Mon, 05 Dec 2005 14:08:28 -0500, Jeff Garzik 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
>
> Patently false.

Maybe some explanation why current in-kernel ieee80211 code needs to be
rewritten will be useful.

1. To support WDS and devices capable to associate with multiple
networks, ieee80211_device needs to be separated to two (or even more,
see below) structures - one hardware dependent (channel and so) and one
link dependent (BSSID etc.).

2. To support AP mode, you need to keep a list of associated stations.
No such list exists now. Furthermore, that list (or that structure) can
be reused also by a client to store information about AP it is
associated to. And - possibly - for a list of APs it can associate to,
i. e. list of found networks. Currently, informations about AP are
hardwired into ieee80211_device structure.

3. Most of WE calls can be handled by ieee80211 itself. The rest should
be propagated to a driver in some easier way than requiring driver to
deal with the whole WE stuff itself. Also, exporting callbacks from
ieee80211 that driver has to set as particular WE handlers seems to be
unnecessary complicated.

4. Callbacks like handle_auth() that were added some time ago are not
needed (for explanation, see corresponding thread on netdev).

5. Some less important things, e. g. current very inefficient code which
deals with found networks.

--
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
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

arjan at infradead

Dec 8, 2005, 4:12 AM

Post #60 of 62 (2868 views)
Permalink

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

> 3. Most of WE calls can be handled by ieee80211 itself. The rest should
> be propagated to a driver in some easier way than requiring driver to
> deal with the whole WE stuff itself. Also, exporting callbacks from
> ieee80211 that driver has to set as particular WE handlers seems to be
> unnecessary complicated.

this argument is analogue to the adaptec SAS driver one about the scsi
host structure. ieee80211 should be a LIBRARY of functions that can do
things, the driver should be able to use the library or not at its own
choice. forcibly making the ieee80211 layer deal with the WE's is the
wrong way for this kind of thing, especially since several layers of the
stack will be optional, so it has to be possible for drivers to go
"until this layer I use the ieee80211 library functions, below that my
own".

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
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 8, 2005, 5:03 AM

Post #61 of 62 (2882 views)
Permalink

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

On Thu, 08 Dec 2005 13:12:44 +0100, Arjan van de Ven wrote:
> this argument is analogue to the adaptec SAS driver one about the scsi
> host structure. ieee80211 should be a LIBRARY of functions that can do
> things,

Unfortunately, it is not possible to implement ieee80211 as a library,
because you need fragmentation, WDS and such funny stuff, which require
ieee80211 (or possibly "softmac") to be a layer between networking core
and a driver.

> the driver should be able to use the library or not at its own
> choice. forcibly making the ieee80211 layer deal with the WE's is the
> wrong way for this kind of thing, especially since several layers of the
> stack will be optional, so it has to be possible for drivers to go
> "until this layer I use the ieee80211 library functions, below that my
> own".

Making ieee80211 (not any possible layer on top of it, but ieee80211) to
handle part of WE for drivers and reexport (or whatever) the rest to
drivers will not take off the possibility to use WE by others. Where is
the problem?

The goal is to make life simpler for drivers. Dealing with WE is not
easy and even if everything which ieee80211 will do is allowing drivers
to register their handlers during allocation of ieee80211_device by
simply setting pointers to their functions (in ieee80211_device or
somewhere), it will be easier (see the thread at
http://oss.sgi.com/projects/netdev/archive/2004-06/msg00463.html to
understand what I mean).

But I agree this is something we can argue about. This is not the main
reason I gave in my mail, so if you still don't agree with me in this
point, please imagine I didn't mention it - it's not something I want to
argue about now and the explanation I gave is I think valid even without
this point.

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
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

mihamina.rakotomandimby at etu

Dec 30, 2005, 2:34 AM

Post #62 of 62 (2902 views)
Permalink

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

On Mon, 2005-12-05 at 20:11 +0100, Jiri Benc wrote:
> That results were implemented (patches were sent
> and not accepted).

May be should you submit your patches to the right persons:
see /usr/src/linux/MAINTENERS.

I dont know where did you submit yours, but that's just a suggestion.
--
A powerfull GroupWare, CMS, CRM, ECM: CPS (Open Source & GPL).
Opengroupware, SPIP, Plone, PhpBB, JetSpeed... are good: CPS is better.
http://www.cps-project.org for downloads & documentation.
Free hosting of CPS groupware: http://www.objectis.org.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
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 Gossamer Threads