https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265066
--- Comment #10 from Andreas Kempe <ke...@lysator.liu.se> --- Created attachment 256976 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=256976&action=edit Updated patch with extre messages and name change. (In reply to Bjoern A. Zeeb from comment #9) Thank you for looking at this! I checked and actually have an updated version of the patch where I added a few more messages that I noticed I had missed while working on blued. I am uploading the newest version of the patch I have with your suggested name change. It is good to hear some work might get done. I have been meaning to share some of my thoughts but never got around to it, because I lost all my steam when I realised the task was too big for me to have time to undertake alone. I think the Bluetooth infrastructure needs a good looking over. The current split between kernel and user space makes some things difficult. HCI connections being handled in user space gave me difficulties with correctly handling the interplay between l2cap connections that have proper socket support, the HCI connection and authentication. Unfortunately, I can't remember the details and would have to dive back into the core specification to refresh my memory. Another issue with how HCI connections are handled is that a crash of the daemon loses track of what connections were active if state is not saved in persistent memory. If you lose the handle, there is no easy way to cause the connection to disconnect from software without resetting the host controller or the Bluetooth device. I think it would probably be desirable to either put the entire implementation in the kernel or user space, not splitting it like it is now. Maybe even looking at doing for Bluetooth what is currently being done for WiFi by importing driver infrastructure from Linux. -- You are receiving this mail because: You are on the CC list for the bug.
