nl/cfg80211 scan result/event handling

nl/cfg80211 scan result/event handling

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1235 bytes --]

Hey,

Just a few notes as I'm thinking about these things. I probably won't be
implementing this quickly so I'm telling you, but who knows, maybe I'll
get around to it and then... Here's hoping for some feedback :)

Right now I'm thinking along the lines of:
void cfg80211_key_threshold_notify(struct wireless_dev *wdev,
				   int txrx_count,
				   u8 *mac);

or
void cfg80211_radar_notify(struct wireless_dev *wdev,
			   phymode, channel, ...)

and then cfg80211 is responsible for sending the appropriate nl80211
messages or doing whatever else to notify userspace.

As for scan results, we want those broadcast as well. I was thinking
that we have basically these choices:
 1) drivers (stack) aggregate data
 2) drivers (stack) call a function for each result
 3) hybrid

I tend towards 3 because it allows both, in a fashion like this:

cfg80211_add_scan_result(struct wireless_dev *wdev,
			 int n_results,
			 struct scan_result **sr);
cfg80211_scan_finished(struct wireless_dev *wdev);

and for the add_scan_result calls cfg80211 simply starts creating the
nl80211 message and then multicasts it to those who want it
(NL80211_GROUP_SCAN or such) on _scan_finished()

Thoughts?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: nl/cfg80211 scan result/event handling

[Dan Williams]

On Sat, 2007-06-16 at 21:49 +0200, Johannes Berg wrote:
> Hey,
> 
> Just a few notes as I'm thinking about these things. I probably won't be
> implementing this quickly so I'm telling you, but who knows, maybe I'll
> get around to it and then... Here's hoping for some feedback :)
> 
> Right now I'm thinking along the lines of:
> void cfg80211_key_threshold_notify(struct wireless_dev *wdev,
> 				   int txrx_count,
> 				   u8 *mac);
> 
> or
> void cfg80211_radar_notify(struct wireless_dev *wdev,
> 			   phymode, channel, ...)
> 
> and then cfg80211 is responsible for sending the appropriate nl80211
> messages or doing whatever else to notify userspace.
> 
> As for scan results, we want those broadcast as well. I was thinking
> that we have basically these choices:
>  1) drivers (stack) aggregate data
>  2) drivers (stack) call a function for each result
>  3) hybrid
> 
> I tend towards 3 because it allows both, in a fashion like this:
> 
> cfg80211_add_scan_result(struct wireless_dev *wdev,
> 			 int n_results,
> 			 struct scan_result **sr);

Just to be clear, 'struct wireless_dev' isn't tied to mac80211 at all,
right?  Cause we're going to need to use these functions in fullmac
drivers too.  And is the n_results/**sr stuff supposed to allow multiple
scan results to be added?  If that's the case, you might want to make
the function end with an 's' too, just to be clear.  "add_scan_result"
makes it sound like it should just add one scan result.

> cfg80211_scan_finished(struct wireless_dev *wdev);
> 
> and for the add_scan_result calls cfg80211 simply starts creating the
> nl80211 message and then multicasts it to those who want it
> (NL80211_GROUP_SCAN or such) on _scan_finished()
> 
> Thoughts?

Sounds fine to me; this is essentially what we've got now and I think it
works ok.  There's two cases where this would be used: (a) a triggered
scan, and (b) background scan.  Should work fine in both cases.

Dan

Re: nl/cfg80211 scan result/event handling

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1642 bytes --]

On Sun, 2007-06-17 at 11:13 -0400, Dan Williams wrote:

> Just to be clear, 'struct wireless_dev' isn't tied to mac80211 at all,
> right?  Cause we're going to need to use these functions in fullmac
> drivers too.

Right. It completely lives in net/wireless or include/net/wireless.h and
is just the abstraction that cfg80211 requires to know that a given
netdev is wireless and where cfg80211 stores stuff it needs. You
allocate this along with the struct netdev and whatever private struct
you need.

>   And is the n_results/**sr stuff supposed to allow multiple
> scan results to be added?  If that's the case, you might want to make
> the function end with an 's' too, just to be clear.  "add_scan_result"
> makes it sound like it should just add one scan result.

Yeah, makes sense to add the 's'. I was thinking that some drivers get
everything in one go so it's more efficient to build it in one go wrt.
allocating the netlink message, but others get results piecewise and we
don't need to bother them with storing them. I'm not sure though whether
cfg80211 should centrally cache and expire scan results for when scan
results are requested but no new scan should be done. I think it
probably should.

> Sounds fine to me; this is essentially what we've got now and I think it
> works ok.  There's two cases where this would be used: (a) a triggered
> scan, and (b) background scan.  Should work fine in both cases.

Yeah, that should work in both cases, although some care will have to be
taken that no background scan goes active while a triggered scan is
running or something like that.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]