Re: [Bluez-devel] bluetoothd D-Bus interface proposals(draft 00.05)

[Claudio Takahasi <cktakahasi@gmail.com>]

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

On 8/29/05, Marcel Holtmann <marcel@holtmann.org> wrote:
> 
> Hi Claudio,
> 
> > Sorry annoy you again, but would like received more suggestions and
> > close this discussion.
> >
> > Marcel, I remember you comment something about improve the sdpd, could
> > you be more clear?
> >
> > The core implementation (bluetoothd) and some hci functions are ready.
> > I am just waiting finish the specification.
> 
> sorry, I am totally behind my schedule and as you saw, I had to deal
> with some weird D-Bus things in the current hcid in the last week. There
> is other stuff that needs my attention, before I can start looking at
> bluetoothd again.


[Claudio Takahasi] 
I understand your problem, Don't worry. Considering that D-Bus is
under development, bugs are common :)

However the basic idea is that bluetoothd should combine hcid and sdpd
> and present an easier interface over D-Bus. This interface should no
> longer be HCI or SDP protocol specific. It should be more profile
> specific and define standard task. In conjunction with the new extended
> inquiry response the bluetoothd must also take care to assemble the
> correct data from the running services and the device name to fully
> fulfil the requirements of extended inquiry response. If the complete
> SDP handling is inside bluetoothd we can do full and easy caching of
> service information of remote devices.


[Claudio Takahasi] 
I didn't see the new extended inquiry response yet. I will try understand 
how it works.
Do you have material about it? Is it related with interlaced inquiry?
Regarding SDP, do you mean put everything inside bluetoothd? I am not 
understanding how 
it should work. As I could undertand you intend provide a complete SDP 
handling inside bluetoothd
without interact with sdpd.
Currently, applications(daemon) that want publish a service, they have to 
connect
with the sdpd(sdp_connect) and register the services. If we move everything 
to bluetoothd we will lost 
the backward compatibility. Another approach is provide a D-Bus interface 
for sdp in the bluetoothd, but in 
this case the bluetoothd will continue connecting to sdpd to register 
services. The last approach is dupplicate 
the functionalities, sdpd and bluetoothd will do the same thing, but the 
last one will available for D-Bus enable 
systems only.

Another comment about bluetoothd IMHO blutoothd should be modular enough to 
make possible 
develop/provide another profiles(pan,rfcomm, dun, hid, hsp, ...) Therefore, 
it should be more than
a daemon to provide hci and sdp services. This is the reason that I comment 
about hierarchical
paths.
/org/bluez/bluetoothd
/org/bluez/bluetoothd/sdp
/org/bluez/bluetoothd/hci
/org/bluez/bluetoothd/pan

Using this approach is easier control permissions in the D-Bus configuration 
file and register/unregister
D-Bus paths.


On the other side we have that D-Bus API problem and if anyone can
> convince the Debian guys to finally move to latest D-Bus release for the
> unstable distribution I would be really thankful. I simple wanna drop
> these crappy workaround, because they make my testing before I can
> release a new version a mess. I saw that Ubuntu even uses D-Bus 0.35 and
> so there is no other distribution with such an old version.


[Claudio Takahasi]
I think you don't need worry about it. After 0.30 D-Bus is more stable and 
probably
it will not change drastically. I didn't see functions name/signatures 
changes. 
The only think that we have to pay attention is the functions to 
extract/append arguments
in the message with number of elements variable. I was informed that they 
should be avoided 
and they will be depreciated.

The next thing is the kernel interface for bluetoothd. I basically don't
> wanna have another daemon listening on the HCI socket and have to deal
> with plug/unplug of devices. These task are already done inside the
> kernel and so it should simply inform the userspace of such events. The
> same applies to connection tracking etc. The kernel needs to know
> everything and I must work on the new interface to tell the userspace
> what is currently going on. For that I will use the special HCI_DEV_NONE
> system socket and the vendor packets type 0xff. So we don't pollute the
> HCI namespace with "stack internal" commands and events and still have
> an easy interface. The other possibility would be to use netlink, but we
> already have most parts of the infrastructure in place and so I don't
> see and need to deal with netlink. And one of the first things that
> bluetoothd must be capable of is to support the kernel internal security
> manager. This means dealing with special events to handle pin code and
> link key requests.


[Claudio Takahasi] 
O my God, it will be fun! A lot of chalenges :) 
Could you provide more details about this section. Currenlty hcid is 
responsible for
handle this events(security and devices). How should be the 
interaction/relation
between hcid and bluetoothd? hcid is already listening for 
HCI_DEV_UP/DOWN/REG/UNREG ...

I agree with provide security services, they are essential.


As maybe some people saw, I already used hcid as a playground for some
> more D-Bus signals. I still need to learn and understand the D-Bus much
> better. So any patches from your specification to bring some of these
> features to hcid would be happily accepted.

[Claudio Takahasi]
I saw a lot hcid D-Bus signals, but currently only signals are sent. 
Services requests are
not being handled, they can be a good starting point. I will analyse better 
and send
patches if possible.

Regards
> 
> Marcel
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle 
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>

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