Hi Michal, > -----Original Message----- > From: linux-bluetooth-owner@xxxxxxxxxxxxxxx [mailto:linux-bluetooth- > owner@xxxxxxxxxxxxxxx] On Behalf Of Michal Lowas-Rzechonek > Sent: Monday, December 17, 2018 1:10 PM > To: linux-bluetooth@xxxxxxxxxxxxxxx > Subject: Plans for meshd > > Hi, > > Given recent patches to mesh, what are your mid to long-term plans to > enable co-existence of bluetoothd and meshd on a single system? You are essentially correct, that the current implementation assumes mesh ownership of the Controller, and there is no co-existence of "Classic Bluetooth" as implemented in the Bluetooth Daemon, on the same controller. So currently, if you want to simultaneously run an ACL connection based application with Mesh, you would do so with more than one controller. (This should already work) I consider this to be a practical approach, because the overhead consumed by ACL connections negatively affects Advertising based communications, and linux in particular handles a practically unlimited number of controllers. Support for devices with controllers that have active ACL connections requires other mesh devices to send more redundant packets to ensure delivery. The primary use cases targeted by this implementation assumes the controller is being used for one or the other. And we want to give embedded platforms the option of not installing meshd if they don't need Mesh, or not installing bluetoothd if they don't need Classic Bluetooth. That said we *do* plan on supporting GATT Proxy Server, but offering this support through the Bluetooth daemon (bluetoothd) on a separate controller. Is this your original question? Same system, but multiple controllers, and both daemons running. Also forward looking, a system might have as many as 5 controllers: 1 for Classic Bluetooth, 1 for Outbound Mesh traffic, and 3 (one on each LE adv channel) for incoming Mesh traffic. And I am not opposed to someone starting a project that will allow the bluetoothd and meshd share a single controller and taking responsibility the reduced performance of each, but that is not work we have planned. > From what I gather (please, correct me if I'm wrong), current implementation > of mesh-io-generic assumes that meshd is the sole owner of the BLE > adapter, because the HCI socket is bound using as HCI_CHANNEL_USER, so at > the moment the daemons are unable to share the same HCI device. Is my > understanding correct? > > regards > -- > Michał Lowas-Rzechonek > Lambda Team Leader > > Silvair > Jasnogórska 44 > 31-358 Krakow > POLAND > > http://www.silvair.com Regards, Brian
