[RFC] rc.d integration for the bluetooth subsystem

[Maksim Yevmenkin]

Panagiotis,

[...]

>> that's fine. please give me some time for more careful review. also
>> shouldn't rc.bluetooth be in /etc instead of /etc/rc.d? its
>> similar to /etc/pccard_ether, is it not?
> 
> If you pick rc.bluetooth, yes. On the other hand if you prefer the
> rc.d version that I posted, it is more like, say /etc/rc.d/netif, so
> it should be in /etc/rc.d. If you are concerned about having a script
> in rc.d that is not executed at boot time, there is also the
> precedent of /etc/rc.d/dhclient and the other scripts with the
> nostart keyword.
> 
> It is also my impression that rc.foo scripts in /etc are being 
> deprecated these days, but I might be wrong. We could ask freebsd-rc
> for a clarification.

yes. basically i'm not sure where your version of bluetooth rc.d script 
should go /etc or /etc/rc.d

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?

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.

thanks,
max