Hi Marcel, On Sat, Feb 21, 2009 at 1:37 AM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote: > 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 was using try_lock to safeguard the code from being re-entrant. will create a new define in netlink.c. > > 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. sounds good. > > 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. PROPERTY can be a nested primitive which holds the parameter <name: value> pair. so NEWHOST takes a list of parameter name:value pairs. did I understand you correctly? Cheers, Alok. -- 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
