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 wrote: > > > > On 8/29/05, 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. > > > [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 > > > >