Maybe embed BTH_LE_GATT_CHARACTERISTIC inside struct winebluetooth_watcher_event_gatt_characteristic_added, then, and just add the extra parts alongside it later.
Makes sense, I've tried to do that in the latest revision, thanks.
And how about the latter question? Do we really get a performance difference from separating all these locks?
So I think apart from the per-device locks, we could perhaps merge `device_list_cs`, `bluetooth_radio.props_cs`, and `remote_devices_cs`. I'll take a stab at this at some point.
I understand the loop pattern, but why do you need to make more than _one_ ioctl? Unlike in BluetoothFindFirstDevice(), you don't need to retrieve every characteristic here, only as many as the caller allocated space for.
Ah, I get what you mean. Yeah, we don't need to necessarily get _all_ characteristics, I missed this. Doing it once should be enough to inform the user if there are more characteristics or not. I have simplified the function in the latest revision (and will do the same for BluetoothGATTGetServices in the next MR)
Sure, but MSDN isn't always accurate, and it might change in the future without us really knowing about it. I always advocate for a FIXME for any parameter we ignore, even if it's documented as being reserved. Especially if we aren't going to check for it and return an error.
Sure. I have added a FIXME for this, thanks.