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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
