If we go with approach to use parameters and let FW or MAC80211
layer to decide what type of scan to do, 

At that point though, is it even meaningful to ask "what type of scan
is this"? Or put another way - what does "scan type" even mean?

then in general the only
difference between different types of scan is what to do with result:
- Normal scan: ssid list, channel list, dwell params, etc...
- Sched scan: ssid list, channel list, interval
- BSSID scan: bssid list, channel list, interval
Action: Report when suitable results are found (in case of Normal
scan it will be at the end of scan)

- Roaming / Autojoin: ssid list, channel list, interval
Action: Connect when suitable results are found

- History scan: bssid list, channel list, interval
Action: Report when buffer is full / almost full

Exactly. But the type of action is something set by the entity that
triggered the scan, right? normal and roam would be equivalent anyway,
no? wpa_supplicant would make a decision to connect - after the results
are coming in.

Oh, then again, maybe you're thinking of full-MAC devices - does a
roam/autojoin scan really already *imply* a new connection? And if so,
do we have to do it that way, or can we remove that type of action and
make a connection decision in higher layers, so it's really the same as
"report when suitable results are found"?

So we can literally distinguish scan types by final action.

Actually I think I'm just misinterpreting your wording - you mean that
we can use the different final actions for the different scan types,
not that we should actually say - in driver/firmware/... - "this is a
history scan because the action is to report buffer full", right?

And for History scan we need new get_scan_results() command.

Does it sound reasonable?

I think it does.

There's a bit more complication wrt. the level of detail in results
though - sometimes the result may include all IEs (normal/sched scan),
sometimes it may not ("history scan") - are we sure we really only need
one new get_scan_results()?

johannes