On Tue, 2019-01-22 at 17:00 +0530, [email protected] wrote:
> > > > It seems that this should be with the existing
> > > > NL80211_SCHED_SCAN_MATCH_ATTR_RSSI, not in this level namespace.
> > >
> > > The band specific rssi thresholds that are being configured are global
> > > across all matchsets whereas NL80211_SCHED_SCAN_MATCH_ATTR_*
> > > attributes
> > > are mostly specific to each matchset. Hence I choose to define
> > > attributes in higher level namespace. In future, whenever we want to
> > > adding support for rssi thresholds per band and per matchset, we can
> > > define attributes within NL80211_SCHED_SCAN_MATCH_ATTR_* namespace
> > > level.
> >
> > But why do we want global ones now?
> >
>
> The global thresholds were there earlier as well. Earlier, we were using
> a matchset with only rssi attribute without any ssid/bssid attribute
> within the matchset. I thought having global attributes for specifying
> global thresholds is better way going forward and avoids unnecessary
> confusion. Mostly, same thresholds will be used for all ssids/bssids in
> general rather than thresholds specific to ssid/bssid. However, I
> couldn't see any disadvantage of using global attributes for this case,
> please let me know if you see any disadvantage/concern with this.
I just think it's more complex code, overall.
To me we now have sort of a fork in the road
global RSSI ---> per-matchset RSSI
\
\--> global band-specific RSSI
so it seems somebody will want to introduce per-matchset band-specific
RSSI eventually, and that just makes it even more complex?
What's the downside of going to per-matchset band-specific RSSI?
johannes
