On Tue, 2016-01-19 at 23:33 +0100, Arend van Spriel wrote: > I looked at our firmware and it has a kinda pipeline, but it uses a > weighted score. So for "band_pref, rssi" the band_pref score would > have more weight than the rssi score and bss-es are sorted based on > the score. So not really throwing things away. Yeah, ok - similar result. It makes sense to keep the next ones too, in case all the ones on the band you preferred weren't usable or something (due to later conditions, like garbled beacons or whatever.) > > But then I understand the whole point of the "primitive" even less, > > since it should be trivial to check that of multiple attributes > > only a single one is specified? > > Not really a single one as rssi_adjust needs two attributes, ie. band > and rssi_delta. Still you are right and we can probably drop the > primitive. Fair enough, not really a single attribute, but a single "behaviour" attribute; the other (band) attribute would just provide data for the behavioural one. I think then I really would prefer one of these options: * pack two u32 value into a tiny struct in the single "rssi_adjust" behavioural attribute, so that it really becomes a single one * make the rssi_adjust behavioural attribute nested with band and adjustment inside * use a rssi_adjust_band attribute, rather than reusing the band_pref one I think the first option is perfectly reasonable (and we do this in other places) and makes for the easiest semantics since we can then just say "specify exactly one of these attributes"? 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
