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

[Marcel Holtmann <marcel@holtmann.org>]

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.

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.

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.

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.

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.

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