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