On Thu, 2013-08-01 at 11:14 +0200, Michal Kazior wrote: > > This seems a bit iffy - you don't differentiate between active/passive > > scans? > > Is there a reason this should be differentiated? Well they don't usually have the same timing, passive channel dwell time usually needs to be longer than on active channels. > > This also interferes a bit with some other scan optimisations that could > > be done at a low firmware level, so I think we should be careful and > > actually say that this is really more intended for measurement use cases > > and not for normal scans? > > > > Or maybe we should have a separate measurement command with similar > > semantics? This all doesn't seem very clear to me yet :) > > Motivation behind this patchset is to simplify ACS implementation and > depend on scan. This also allows easier fallback from survey-based ACS > to BSS-based one. Sure, I understand. > Other use cases are a side-effect so perhaps clarifying the intent in > the docs is enough. I'm just saying that this is a fundamentally different usage than actual scanning. Let's say for the sake of the argument I find a way to scan channels quicker and implement that in my device (hw_scan). I don't think this is too far-fetched, imagine I have an 80MHz capable device and can send probe request 4x transmissions on all the subchannels, if somehow I manage to separate the receive then I could scan 4x as quickly. I don't think this particular thing is possible but I could imagine scan optimisations like it. Now this comes along - and suddenly the API requires that you stay on each specified channel for the given period of time. Any such "non-traditional" scan optimisations would have to be given up, so in a sense this fundamentally alters the semantics of the scan primitive, where before it was "give me the list of networks (with these SSIDs) on these channels" it now becomes "go to each channel, stay there for this amount of time and ..." That's what I'm worried about - the implicit semantic change here. 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
