This probably is thread-safe, but I'd kind of prefer not to have to think about it, and just use AUTOGENERATED_DEVICE_NAME or whatever the flag is. Not to mention there's no reason to give the device a specific name here.
I didn't go with `FILE_AUTOGENERATED_DEVICE_NAME` mostly because I don't see it being used anywhere else except for creating the root PnP manager in `wine_enumerate_root_devices`. Rewritten to use it now, thanks.
The PDO directly having children is a bit weird, although not impossible. Is this what Windows does?
Yeah. The PDO hierarchy for Bluetooth PHYs, devices and services is odd, but probably makes sense for how the Bluetooth stack on Windows is structured. I have provided an example of what `pnputil` looks like on Windows [here](https://gitlab.winehq.org/-/snippets/23). There is an enumerator bus child for every PHY, which then is the parent of remote devices found on that radio. The `bthleenum` and `bthenum` drivers are the minidrivers that probably implement the HCI layer for the Bluetooth PHY, which is probably what necessitates an additional enumerator bus.
Why the separate CS?
Some properties, like the RSSI and transmission power, can be updated quite frequently during advertisement/inquiry (though it hasn't been implemented yet). Making the locking slightly more fine-grained lets updating them not step on the toes of LE-related IOCTLs on devices.
Also, this is a preexisting pattern, but bitfields are kind of pointless if you aren't going to pack them. They're also kind of pointless anyway if you have less than 8 of them—these could be stdbool, and would be more declarative (and kinder to the compiler, not that that matters) while taking up the same amount of space.
Fair, fixed this, thanks.
This logic seems weirdly complex, can we just use offsetof(services, services[count]) instead?
I think it should also be possible to define the struct using a sizeless array. I don't know if you can safely use sizeof() in that case, but I'm not sure we want to use sizeof() anyway, probably better is offsetof(services, services[0]).
Well, the idea was to have the same semantics as `IOCTL_BTH_GET_DEVICE_INFO`, but I suppose that isn't really needed since this is strictly a Wine-only IOCTL.
Is there a particular reason not to just use BTH_LE_GATT_SERVICE in the driver directly, and move most of this logic there?
Hm, the only substantial "logic" in this code IMO is in `uuid_to_le`, and I made the choice to perform this conversion in userspace as:
* BlueZ only provides the full UUID for all GATT entities, and I feel the driver should do as little as possible with the data it receives from the bluetooth service. * Using `BTH_LE_UUID` also increases the size of the IOCTL buffer (albeit by a single `BOOLEAN`).
When would this happen?
When would we fail to open the device?
Yes, this is likely not necessary. I mirrored this code from BluetoothFindNextRadio, assuming this is the standard logic for enumerating device nodes.