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

Claudio Takahasi
2005-08-30T18:16:51Z

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

Marcel,

Regarding the special HCI_DEV_NONE system socket with vendor packet type. Do
you
have a patch for it or it just ideas for BlueZ improvements? What are
exactly the events that
you want send in this socket?

BR,
Claudio.

On 8/30/05, Claudio Takahasi <cktakahasi@gmail.com> wrote:
>
>
>
> 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: 8956 bytes --]