Date: Thu, 20 Oct 2005 20:54:42 +0300 From: Panagiotis Astithas <past@ebs.gr> To: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> Cc: freebsd-bluetooth@freebsd.org Subject: Re: [RFC] rc.d integration for the bluetooth subsystem Message-ID: <4357D9E2.6010701@ebs.gr> In-Reply-To: <4357CEA5.1000308@savvis.net> References: <43519460.1090605@ebs.gr> <1129491219.1616.18.camel@localhost> <4353DBBC.2000508@savvis.net> <43541F79.6040008@ebs.gr> <43554BCE.7090309@savvis.net> <4355FD0C.2090702@ebs.gr> <4356D12F.7000006@savvis.net> <43576A9D.1050209@ebs.gr> <4357CEA5.1000308@savvis.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Maksim Yevmenkin wrote:
>>> 2) what is the reason for calling "/etc/rc.d/{hcsecd,sdpd}
>>> {start,stop}" from "bluetooth_start()/bluetooth_stop()"? shouldn't
>>> these be controlled by their own xxx_enable variables? for example
>>> you do not need sdpd(8) running unless you want to provide services
>>> to the remote clients. also both sdpd(8) and hcsecd(8) bind to "any"
>>> bd_addr, so there is no reason to restart them even if particular
>>> device comes and goes. what is important here is to kill daemons
>>> (providing services, such as rfcomm_pppd(8)) if they were bound (i.e.
>>> listening) to the device that went away. however this is a corner
>>> case. usually service daemons listen on "any" address and thus there
>>> is no need to restart them.
>>
>>
>> I opted for simplicity and ease of use. I think users don't comprehend
>> the interactions between sdpd, hcsecd, the bluetooth stack, etc. most
>> of the time. The typical use case I have in mind is a user who plugs
>> in his bluetooth dongle to send or receive files. Since we don't have any
>
>
> if one does not understand interaction between hcsecd/sdpd/etc. then
> perhaps better documentation must be written? if one refuses do read
> documentation then i'd just say, have "sdpd_enable" and "hcsecd_enable"
> set because they required. there is harm in having them both running all
> the time.
>
>> user-friendly applications in the base system, I think a user would
>> prefer to initiate a device-to-PC transfer from the device. In this case
>
>
> device to PC transfer setup is _harder_. simply because you need to run
> sdpd _and_ service daemon (such as obexapp). so you need to understand
> how service daemons interact with sdpd etc. as far as user-friendly
> applications, you can install comms/obexapp from ports. just to send
> file from pc to device (with obex push) is _very_ simple. you do not
> need to setup anything. getting files from device (with obex file
> transfer) is slightly harder because most devices require
> authentication, so you need to setup pin code with hcsecd and have it
> running.
>
> obexapp (and other things) are made as ports because of gpl.
>
>> he will need both hcsecd and sdpd, right? It is also the default
>> behavior in Windows and in Linux KDE, I think. You get all the
>> necessary services running before starting a connection. I am also
>> considering porting gnome-bluetooth for the same reason.
>
>
> once again, kde, gnome-bluetooth etc. are gpl. so they will have to go
> to ports/.
>
>> I understand that your approach with sdpd_enable and hcsecd_enable is
>> more fine-grained, but I wonder if we could combine it with
>> hassle-free operation for the common case. I agree with all the rest
>> that you mention about the address binding.
>
>
> i'm afraid, i have to object to start/stop'ing hcsecd and sdpd from
> bluetooth rc.d script. it just not right, imo. what if i have more then
> one bluetooth device connected? the moment i pull one of them off hcsecd
> and sdpd will be killed. not good.
>
> to summarize:
>
> 1) hcsecd and sdpd should be considered as "special" daemons. average
> bluetooth user should have them both running at all times.
>
> 2) to make hcsecd less painful for users it has to be enhanced, i.e. it
> should support helper application for pin codes, i.e. instead of
> specifying pin code, user specifies a program to be called to obtain pin
> code. default entry in hcsecd.conf then will be changed to call external
> program to obtain pin code. something like xdialog.
>
> 3) bluetooth rc.d script should only setup devices. it also should have
> some sort of extension to start/stop service daemons bound to the
> particular device, however it should not touch hcsecd and sdpd.
I understand all of the above and have no problem whatsoever. I'll wait
for you to commit things the way you feel they should be implemented and
then I'll try to come up with suggestions for improvement if I can
find any.
Cheers,
Panagiotis
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4357D9E2.6010701>