This looks like a rewrite of BTH_LE_GATT_CHARACTERISTIC. Why not use that struct directly?
There are a [bunch of additional flags ](https://github.com/bluez/bluez/blob/master/doc/org.bluez.GattCharacteristic.... `org.bluez.GattCharacteristic` objects that `BTH_LE_GATT_CHARACTERISTIC` does not support. The driver doesn't use them ATM, but they are utilized in the WinRT APIs, so I'll likely add them in the future.
In this patch series this is only ever taken under props_cs. Is there a point to having this separate CS? Even if there will be a case where it can be taken by itself, will it really make a measurable performance difference?
(The same can be asked of the four other mutexes already used in this file. Those at least are already used by themselves, but do we really need all of them?)
So, `chars_cs` does not get used by itself in this series, but is meant for future MRs, where the driver creates and exposes PDOs for individual GATT services on every LE device (which is needed for [`BluetoothGATTGetCharacteristicValue`](https://learn.microsoft.com/en-us/windows/win32/api/bluetoothleapis/nf-bluet...) as it operates on HANDLEs to _services_, not devices).
You don't actually use this later, but instead check ->count directly in the caller. Since this is a private ioctl you might as well get rid of everything you're not using.
Doesn't IoStatus.Information need to be set so that ntoskrnl knows how many bytes to transfer in the reply?
That doesn't look right. Also, the spacing is a bit off.
Oops, thanks.
Why the loop? The API function only asks for the first N and the total count; you can just allocate a buffer large enough to hold the first N and then return it, can't you?
It's the same idea as `IOCTL_BTH_GET_DEVICE_INFO` in bluetoothapis/main.c. This allows for the number of GATT services/characteristics to change between two successive IOCTL calls, which might happens if the system is discovering a LE device that hasn't finished exposing all of its available services/characteristics.
Do we want a FIXME for the flags?
For both BluetoothGetGATTServices and BluetoothGATTGetCharacteristics, the MSDN documentation lists `BLUETOOTH_GATT_FLAG_NONE` as the only flag option, which is 0.
I always feel that this sort of thing is unnecessary. If a test failed, it needs to be fixed, no matter if there's one failure, many failures, or a crash.
Fair, removed this is the latest revision, thanks.