ACL link creation in userspace

Bluez-users Marco Pracucci 2 participants 2 messages Jan 12, 2007 Bluetooth drivers

Share & tools

Marco Pracucci

author

2007-01-12 15:36 UTC #0 lore raw

Dear Marcel,

I would like to receive your opinion about ACL link created in userspace. I know that you ever discourage the creation of an ACL link inside an application, but I would like to better understand the reasons.

I have an application that needs to read remote features, remote version and search for services (SDP). Bluez provides API to read remote features and version, but the application should pass the ACL handle as argument. So, I think there are just two solutions:
1) Get the ACL handle (ioctl), if there is already an ACL link
2) Create an ACL link (hci_create_connection), if no ACL link has been established yet

I don't want to establish the ACL link more that 1 time for remote device, so I think that I must create the ACL link in userspace if there is no ACL already established. However, I get several errors that I suppose are collateral effects of this solution. For example, an error occours if there are 2 threads (in parallel) that:
- hci_create_connection()
- read remote features
- read remote version
- sdp_connect() error: Operation already in progress

Can you explain me why I should not create an ACL link in userspace? Do you have any idea how to bypass this limitation?

Thanks,
Marco Pracucci

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

Marcel Holtmann

maintainer

2007-01-12 16:12 UTC #1 lore raw

Hi Marco,

Quoted 22 lines

I would like to receive your opinion about ACL link created in userspace. I know that you ever discourage the creation of an ACL link inside an application, but I would like to better understand the reasons.
I have an application that needs to read remote features, remote version and search for services (SDP). Bluez provides API to read remote features and version, but the application should pass the ACL handle as argument. So, I think there are just two solutions:
1) Get the ACL handle (ioctl), if there is already an ACL link
2) Create an ACL link (hci_create_connection), if no ACL link has been established yet
I don't want to establish the ACL link more that 1 time for remote device, so I think that I must create the ACL link in userspace if there is no ACL already established. However, I get several errors that I suppose are collateral effects of this solution. For example, an error occours if there are 2 threads (in parallel) that:
- hci_create_connection()
- read remote features
- read remote version
- sdp_connect() error: Operation already in progress

Quoted 2 lines

Can you explain me why I should not create an ACL link in userspace? Do you have any idea how to bypass this limitation?

every ACL and SCO connection needs its representation inside the kernel and the driver model. The upper layers like L2CAP rely on this being handled by the kernel. This is important for establishing a L2CAP and for terminating them. In the case no ACL link exists the kernel has to create one and if the last L2CAP terminates the kernel has to start the disconnect timer and if no other user comes along terminate the ACL link to not waste power on unused piconets. This is essential and must simply work. The only instance that can have full control over these things is the kernel itself. And as you already realized you have to avoid parallel use. The kernel is exactly doing this. The latest kernel releases even do more. In case the L2CAP create will be canceled before the ACL link establishment succeeds, the kernel automatically cancels this process. This then free the Bluetooth chip for other tasks which is really important since the chip can only to one page or inquiry operation at a time. Secondly the kernel automatically retries the connection establishment if the Bluetooth chip indicates it was busy. This involves watching out for inquiry and remote name events. This all together makes it wrong to establish any ACL link via raw HCI commands from the userspace. Even in the case of hcid we moved away from doing this at all. It is not suitable for the userspace to keep track. Instead we use the L2CAP raw socket to establish the ACL link. And if hcid is not doing it then certainly you shouldn't do it either.

So if you wanna do a SDP search anyway, then it is totally stupid to create the ACL link first. The kernel will do it for you anyway and you shouldn't mess it. And btw. the so needed ACL handle can be retrieved via socket options on the L2CAP socket that is used by SDP.

Regards

Marcel