[Bluez-devel] hcid and bluetoothd

[Claudio Takahasi <cktakahasi@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2679 bytes --]

Hi Marcel,

You said in an old e-mail that hcid is your playground for D-Bus services. 
Probably, hcid D-Bus should be the starting point for bluetoothd.

I would like to align your ideas to avoid future reworks.

D-Bus provides 4 types of messages:
1. Method call
2. Method reply
3. Signals
4. Error
Currently, only signals are sent. The following signals are sent as result 
of the hci commands:
- InquiryStart
- InquiryResult
- InquiryComplete
- RemoteName
path: /org/bluez/DevAgent
interface: org.bluez.DevAgent

The topics that I want discuss are:
1. hcid signals
In my opinion it is not necessary send signals to notity inquiry 
start/complete. Only signals for news devices are enough. 
Another aspect is, inquiry result can contain repeated devices. This 
approach could cause D-Bus app client overhead(inconsistency), by other hand 
if periodic inquiry is active repeated signals must be sent because more 
than one client can be filtering these signals and they can start at 
different time. :)

2. hcid and bluetoothd object path
What is the object path that you want use?
I suggested in an old email use a hierarchical paths. bluetoothd can be the 
main object path provided at /org/bluez/bluetoothd, hci D-Bus services could 
be provided at /org/bluez/bluetoothd/hci

3. D-Bus services
hci D-BUS services is the next step, I am going to starting coding ASAP. 
Regarding inquiry requests, what kind of implementation do you prefer, send 
method reply message or send only signals(like the current)?
If you use signals, all D-Bus client capturing D-Bus hci signals are able to 
see the new devices found. Using a method reply only the peer (requestor) 
will receive. Using a method reply approach, we can implement device class 
filters and avoid repeated devices. We have the same problem for remote 
name, disconnect, authentication/security, info, role switch and display 
connections.

4. bluetoothd
There are shared codes like(pand/bnep.c, pand/sdp.c, hidd/sdp.c, ...) that 
we need be aware.
It is NOT clear for me how hcid and bluetoothd should work. hcid must be 
running all the time, but the hci D-Bus service will be running only if the 
system has a D-Bus system daemon running. Therefore, who should register the 
hci object path? IMHO, bluetoothd should centralize all D-Bus services. It 
will not be easy separate the "normal" code from the "D-Bus code". Maybe 
your "new interface" that your are defining can solve this problem.

5. new interface
You said that a new interface for kernel and the userspace communication is 
being defined. What is the current status?


Regards,
Claudio.

[-- Attachment #2: Type: text/html, Size: 2853 bytes --]