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

Paul Hedderly
2005-08-30T10:07:55Z

I just looked and... dbus 0.36 is in experimental currently... so
hopefully should make it to unstable RSN.

--
Paul

On Mon, Aug 29, 2005 at 11:46:35PM +0200, Marcel Holtmann 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.
>
> 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