https://bugzilla.kernel.org/show_bug.cgi?id=198685 --- Comment #5 from Nathaniel McCallum (npmccallum@xxxxxxxxxx) --- Let me be more clear about my usage pattern. We operate in a standard request/response schema. When a request is ready to send to the bluetooth device, the first thing we do is start a timeout callback: https://github.com/freeu2f/u2fhid2bt/blob/master/gatt.c#L480 Then we call AcquireNotify: https://github.com/freeu2f/u2fhid2bt/blob/master/gatt.c#L484 If this succeeds, we make an EPOLLIN event: https://github.com/freeu2f/u2fhid2bt/blob/master/gatt.c#L334 Next, we read the GATT attribute which defines the protocol MTU (possibly different than the BTLE MTU): https://github.com/freeu2f/u2fhid2bt/blob/master/gatt.c#L344 Then we write the request packet: https://github.com/freeu2f/u2fhid2bt/blob/master/gatt.c#L287 Which is possibly over multiple frames: https://github.com/freeu2f/u2fhid2bt/blob/master/gatt.c#L224 At this point, the only outstanding events are the timeout and the epoll on the fd. When frames are received on input, we try to reassemble the response packets. If a keep-alive packet is received, we restart the timeout: https://github.com/freeu2f/u2fhid2bt/blob/master/gatt.c#L151 If a response is received, we are complete so we close the fd: https://github.com/freeu2f/u2fhid2bt/blob/master/gatt.c#L167 If the timeout event fires, we also close the fd: https://github.com/freeu2f/u2fhid2bt/blob/master/gatt.c#L92 We don't call any dbus methods outside of this workflow. Since the first thing we do is acquire the fd and the last thing we do is close the fd, I think our application is working within the parameters of the bluez API. -- You are receiving this mail because: You are the assignee for the bug.-- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
