Re: [PATCH 09/13] mac80211: remove hw_scan callback

[Dan Williams <dcbw@redhat.com>]

On Fri, 2007-04-27 at 16:16 +0100, Andy Green wrote:
> Dan Williams wrote:
> 
> > we're not being open enough to functionality that might be in hardware.
> > Holding a 100% software line with mac80211 is just IMHO wrong and
> > short-sighted.  The stack needs to be flexible WRT to the hardware
> 
> Yeah but this isn't "in hardware" -- it's in firmware: software that

I know that.  But to the driver, it might as well be in hardware.  The
driver and stack doesn't care where the functionality lives (silicon or
firmware) as long as the firmware does what's needed.

> runs of a different, vendor-specific, CPU.  Let's not talk about magic
> and impressive "hardware" when the truth is we only talk about the same
> software action on another CPU.  The problems with this particular
> offload to firmware:
> 
>  - it is vendor-specific

So is everything a driver does because the vendors make the hardware and
firmware.  We never get anywhere by being vendor-hostile.  We also never
get anywhere by kissing vendor ass.  We need to toe a line in between.

>  - it is not time-critical.  In fact it just sits there for tens of ms.
>  The extra us lost going through mac80211 when it wants to change the
> frequency should not be measurable.  It's not like it is some special
> DSP in there that is computing PI faster than the main CPU in the box
> can.  It is just changing the frequency now and then, which can
> perfectly well be done in the stack

I'm using hw_scan as a vehicle for my larger point.  But the point is
still valid even if hw_scan is not time critical.

>  - it is not exploitable in other ways.  If we want to talk about
> "short-sighted", let's talk about managing what can be very generic RF
> hardware in a way that can never do anything but IEEE802.11a/b/g actions

We can't and shouldn't try to coerce every piece of hardware into a 100%
userspace-controllable SDR.  While that would pretty much solve all
_our_ problems (but not everyone else's), it's a pipe-dream and
unrealistic.

> > capabilities of the parts that we expect to use it.  Saying no to
> > hardware scanning just because it can also be done in software too is
> > wrong.
> 
> To be clear, this isn't a "hardware" action, just an opaque software API
> specific to that chipset, and that runs on a CPU in the chipset.
> 
> > with.  It's already in, right?  Ripping it out for a 100% software
> > agenda is wrong.  Let's take out crypto offload then too if we're going
> 
> The iwlwifi proposal is for an opaque vendor-specific firmware API, that
> is also "100% software".  Don't get confused by the bogus magic alleged
> "hardware" nomenclature.

I've been burned by wifi firmware/hardware a lot in the past.  All
firmware is a black box API.  But the reality of life is that we're not
going to open all vendor firmware overnight, and I can't actually think
of any vendor that provides the source and build tools for their
firmware.  That's a reality we have to deal with.  We can and should
encourage openness; but hostility gets us nowhere.

Just because it's a black box _doesn't_ mean we make it impossible to
utilize specific features that some hardware has, like crypto offload or
hwscan.  _That's_ the short-sighted part.  We need to keep flexibility
in the stack to make this sort of thing possible and let people
experiment with it.

Dan

> > to take a consistently 100% software line.  Again, it's not either
> > software or hardware; it's a spectrum of capabilities and we shouldn't
> > be making the stack _less_ flexible.
> 
> Yeah let's make the stack completely flexible and either keep control of
> the scan action in the stack, or eventually move it to usermode, in both
> cases doing the scan action well ONCE for ALL drivers.
> 
> -Andy