Hi Ilia, > -----Original Message----- > From: linux-bluetooth-owner@xxxxxxxxxxxxxxx [mailto:linux-bluetooth- > owner@xxxxxxxxxxxxxxx] On Behalf Of Ilia, Kolominsky > Sent: 12 September 2011 16:13 > To: Marcel Holtmann > Cc: ilia.kolominsky@xxxxxxxxx; linux-bluetooth@xxxxxxxxxxxxxxx > Subject: RE: [PATCH bluetooth-next] Added force_acl_master param for > bluetooth module > > > -----Original Message----- > > From: Marcel Holtmann [mailto:marcel@xxxxxxxxxxxx] > > Sent: Monday, September 12, 2011 5:11 PM > > To: Ilia, Kolominsky > > Cc: ilia.kolominsky@xxxxxxxxx; linux-bluetooth@xxxxxxxxxxxxxxx > > Subject: RE: [PATCH bluetooth-next] Added force_acl_master param for > > bluetooth module > > > > Hi Ilia, > > > > > > > This param allows role switch request while accepting a new acl > > > > > connection. This is an enhancement to l2cap L2CAP_LM role > > switching > > > > > capability which allows requesting role switch without > > modification > > > > > to the application code. It was observed that operating as a > > master > > > > > of piconet (as oposed to scatternet config) is beneficial when > > > > > qos (flow_spec) guarantees are requested. > > > > > > > > <snip> > > > > > > > > > module_param(enable_le, bool, 0444); > > > > > MODULE_PARM_DESC(enable_le, "Enable LE support"); > > > > > +module_param(force_acl_master, bool, 0644); > > > > > +MODULE_PARM_DESC(force_acl_master, "Always try to switch to > > master > > > > role on ACL link"); > > > > > > > > using kernel module parameters is not an acceptable API/ABI for > > this. > > > It is not API/ABI, it is a way to configure a system without > > modifying > > > application code and it’s as useful as the other Bluetooth module > > > params. > > > > no, we use kernel parameters to on purpose not enable features that > > have > > not passed qualification yet. We do not use it for general purpose > > configuration. > > > > And btw. what is wrong with the setting lm to master via hciconfig? > You are right, I missed this functionality. > > That > > said, I am pretty much against general purpose setting that are not > > really bound to any specific service/profile. The sum of profiles > > should > > define a proper policy and not some magic global setting. Otherwise > you > > easily run into dead-lock scenarios. > I am not sure I understand the relation to deadlocks in this context, > but since this functionality already exists in hciconfig, I guess > we are done here. The deadlock would be if two devices try to connect and both try to force themselves to be master. This will not cause a connection to succeed - this will create an unhappy user. Even if the function is in hciconfig, adding new ways of doing something wrong is still not right. We've all tried to move away from fixing roles over the years. Marcel put it very well that the link role policy should be based on the sum of profiles, rather than a global setting. Tim ________________________________ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. ��.n��������+%������w��{.n�����{��� �^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
