So, the _only_ flag for controlling what kind of inquiry needs to be performed is `LUP_CONTAINERS`. If it's there, WSALookupServiceBegin will look up Bluetooth devices. If it's not, it'll go through Bluetooth services (on either the local radio(s) or a remote device, determined by `WSAQUERYSET` fields). The documentation doesn't do a great job of explaining this (though the API itself is quite unintuitive to begin with). I've added some documentation to ``sh_lookup_service_begin` explaining this.
So LUP_NOCONTAINERS is ignored?
I might have misunderstood your original question, apologies. What I meant was that `LUP_CONTAINERS` and `LUP_FLUSH_CACHE` are only used for `WSALookupServiceBegin`, and ignored for `WSALookupServiceNext`. That's because the lookup type gets set during `WSALookupServiceBegin`, while `WSALookupServiceNext` only iterates through the results.
Either way, why are we still keeping the flag inside of ws_bth_query_ctx and not putting it in ws_lookup_service_ctx?
The flag informs `WSALookupServiceNext` what kind of lookup results does the handle store, and therefore which union field we should be using to iterate. Once we have support for SDP service lookup, the union would have a `struct ws_bth_query_service` field, and we'd access it if `lookup_devices` was set to false. That way, `lookup_devices` serves as the tag bit for the union, and IMO it's clearer for it to be alongside the union.