Hi Alok, > As per our last discussion, i am attaching a patch for the generic > netlink interface. > I am also attaching a test program (can be compiled with -lnl ) to > test the interface. > > I am using "flags" to bring up the device and returning "changed", > which indicate the changed bits in the flags. > right now the module only supports 'up', 'iscan' and 'pscan'. > so i can issue a NEWHOST command with HCI_UP | HCI_PSCAN | HCI_ISCAN. > I am not sure if this is the right approach. > OR Do you want individual commands for operations ? the first thing that we have to change the try_lock() change. We can't do that. It has way to many implications on the code. So why do you really need the try_lock() in this case. And if, then don't change current locking code. Just create a new define for the the try_lock() case. I am thinking about not exposing the ->flags directly and just creating a new one for the netlink interface. For example for PSCAN and ISCAN I like to have clear primitives that say connectable, discoverable etc. We did a lot of changes in the D-Bus API for 4.x during the last month and the best way would be if the netlink API reflects these changes in a more closer way. So it might be better to just have primitives that map 1:1 the properties powered, connectable, discoverable etc. We could actually just have PROPERTY primitive and then turn the properties into parameters. Netlink should be fine with listing multiple parameters in the same message. What do you think? Regards Marcel -- 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
