[RFC] rc.d integration for the bluetooth subsystem

[Panagiotis Astithas]

Maksim Yevmenkin wrote:
> 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?

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.

> 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 
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 
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.

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.


Regards,

Panagiotis