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 >