Date: Thu, 20 Oct 2005 10:06:45 -0700 From: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> To: Panagiotis Astithas <past@ebs.gr> Cc: freebsd-bluetooth@freebsd.org Subject: Re: [RFC] rc.d integration for the bluetooth subsystem Message-ID: <4357CEA5.1000308@savvis.net> In-Reply-To: <43576A9D.1050209@ebs.gr> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Panagiotis,
[...]
>> the other questions i have is
>>
>> 1) was there any particular reason to put "shutdown" word into
>> "KEYWORD:"? the way i understand it: your bluetooth script will be
>> called with "stop" command on system shutdown, however there will be
>> no device name, so ${dev} will be unset. am i correct here?
>
> Actually if you don't put in the "shutdown" keyword, the script is
> skipped for faster shutdown. I figured there was a need to perform the
> shutdown_stack subroutine, so I added it. However I think you are right,
> on system shutdown ${dev} will be unset, so the keyword is probably
> meaningless. I should try to perform a system shutdown with my USB
> dongle still plugged in to see if there are any error messages.
fine
>> 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.
thanks,
max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4357CEA5.1000308>