On Thursday 26 April 2007 17:57, James Ketrenos wrote: > With a penalty to battery life and an increase in the amount of time a scan > takes. There are improvements that can be made to make the software > scanning faster, but at a penalty of added complexity on both the driver > and the stack side -- for no *real* gain for users that have cards that can > offload the scan. > Sure there is. Smaller firmware means firmware that's less likely to malfunction, which seems to be an issue. I don't see what you're saying about added complexity on the driver side. Eliminating the hw_scan callback reduces driver complexity. The increase in complexity on the stack side is offset by the fact that no driver/firmware/hardware needs to implement their own clever scanning algorithm. > > the use of the hw_scan callback breaks the AP autoconfiguration code > > in ieee80211_sta.c due to its inadequate design. > > Is it breaking it just due to the auto-configuration code not knowing when > to configure things? > Yes, because .. > > Calling hw_scan starts a > > hardware scan, but there is no way to know when the scan is completed. > > That needs to be improved. > This is exactly the issue. > > Even if that problem were addressed, I still wouldn't like it as the > > design of the hw_scan callback is deficient in a number of other ways and > > is completely inapplicable to all other hardware/firmware softmac designs > > that I know. > > Given that there are things we can do as a result of the hw_scan that we > can't do on the host without imposing greater system load and slower scan > results, I really don't want to lose the ability to support hardware > offloading of scanning. > How fast is hardware scanning? What part of software scanning is slowing things down? What's the big bottleneck that justifies moving this to hardware? Are you sure it cannot be eliminated? Why haven't any other vendors chosen to offload scanning like this? > Could you voice some of the "other ways" the current hw_scan callback is > deficient? > Sure. In addition to not being able to find out when the scan is completed.. - There is no way to specify what channels to scan. - There is no way to specify a passive scan. - The probe frame that is used is fixed with the exception of the SSID. - There is no corresponding interface for the userspace MLME. This isn't very important, however. I am more interested in what problems in software scanning need to be solved by moving to hardware scanning. > I'm fine with us overhauling how hw_scan works and integrates with the > stack, but an all out ban on hardware scan offload just doesn't make sense. > The host can do all RC4 and AES encrypt/decrypt too but certainly we would > prefer the hardware to do that for us, right? > The host can do TCP/IP too but certainly we would prefer the hardware to do that for us, right? Well, referring to TOE is unfair, but it makes the point that only some things make sense in hardware. Softmac is the result of removing the things that don't. > In the short term, I would rather we leave hw_scan in the code and have the > users that currently rely on hw_scan just have to manually configure the AP > selection until such time as the in-kernel-AP-selection-policy code works > with hw offloaded scan. > What incentive does that give to fix the code? Leaving broken things in for the sake of out-of-tree drivers does not appeal to me. -Michael Wu
Attachment:
pgpEpDe7Fbsga.pgp
Description: PGP signature
