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.
Attachment:
pgpgl2QRhfXMK.pgp
Description: PGP signature
- Follow-Ups:
- Re: [Bcm43xx-dev] Broadcom 43xx first results
- From: Jouni Malinen <[email protected]>
- Re: [Bcm43xx-dev] Broadcom 43xx first results
- References:
- Broadcom 43xx first results
- From: [email protected]
- Re: [Bcm43xx-dev] Broadcom 43xx first results
- From: Michael Buesch <[email protected]>
- Re: [Bcm43xx-dev] Broadcom 43xx first results
- From: Jouni Malinen <[email protected]>
- Broadcom 43xx first results
- Prev by Date: [PATCH] Extend RCU torture module to test tickless idle CPU
- Next by Date: Re: 2.6.13.2 crash on shutdown on SMP machine
- Previous by thread: Re: [Bcm43xx-dev] Broadcom 43xx first results
- Next by thread: Re: [Bcm43xx-dev] Broadcom 43xx first results
- Index(es):