Re: [RFC 1/3] nl80211: add spec scan flag

[Johannes Berg <johannes@sipsolutions.net>]

On Wed, 2012-11-28 at 13:35 +0100, Johannes Berg wrote:
> On Tue, 2012-11-27 at 20:01 +0100, Simon Wunderlich wrote:
> > This flag indicates that a spectrum scan is requested, if supported.
> 
> That "if supported" here is pretty problematic. There's no way to know.
> Feature flag maybe?
> 
> Also, there are scan flags now. However, I don't see that this should
> (ab)use the scan function. It doesn't seem likely that you want to do
> this while you're sending probe requests, etc. OTOH, it seems likely
> you'd want identical dwell times on all channels to have comparable
> values, which isn't the case here.
> 
> I really think you need to decouple the API for this from scanning.

And then you can also define APIs to get the data out. While I realize
that the data is implementation-dependent, you could have an enum that
indicates the data format and describes it:

@NL80211_SPECTRAL_DATA_ATHEROS: u8 rssi,ext_rssi,noise,fft_data[] ...

enum nl80211_spectral_data {
	NL80211_SPECTRAL_DATA_ATHEROS,
	...
};

Then you can define a function to send the data to the userspace socket
that asked for it (yes, if you have a separate command you can send it
only to that app... wohoo! :P ) and don't even have to store it in the
kernel...

So bottom line is that I think there are two choices:
1) for a proof of concept, implement it in debugfs only, in ath9k only,
   with e.g. a debugfs file that sets a flag that then triggers the
   spectral scan when you do a scan (using sw_scan_start, config hooks)
   --> no need to modify nl80211 at all
2) implement some well-defined API in nl80211, but don't tie it to
   scanning or a debugfs implementation of getting the data out, with
   versioning of the FFT data packets etc. so it can be updated later
   without breaking everything

This hybrid isn't a good approach at all.

johannes