Date: Thu, 20 Oct 2005 12:59:57 +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: <43576A9D.1050209@ebs.gr> In-Reply-To: <4356D12F.7000006@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43576A9D.1050209>