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

[Claudio Takahasi <cktakahasi@gmail.com>]

[-- 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 --]