Marcel,
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 ?
Let me know what you think of this.
Cheers,
Alok.
Hi Marcel,
On Sat, Feb 21, 2009 at 1:37 AM, Marcel Holtmann <[email protected]> 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.
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
Hi Marcel,
I am attaching a modified patch for the netlink interface. The changes are:
1. Adding a HOST command. It take INDEX and EVENT as parameter. EVENT
can be UP or DOWN.
this is similar to hciconfig hci0 up/down.
2. Registering a bluetooth-events multicast group. Userspace can
subscribe to this group and receive the following events
a. HOST events (device is up or down through 'changed' flag)
b. NEWHOST (a new device is registered)
c. DELHOST (an existing device is unregistered)
All above events include the INDEX.
I am attaching a simple program (listen.c) which can be used to test
and above events.
It subscribes to bluetooth-events grp and listens to the events.
Do let me know what you think of it.
Cheers,
Alok.
On Mon, Feb 23, 2009 at 7:10 PM, alok barsode <[email protected]> wrote:
> Hi Marcel,
>
> On Sat, Feb 21, 2009 at 1:37 AM, Marcel Holtmann <[email protected]> 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.
>