From owner-freebsd-bluetooth@FreeBSD.ORG Thu Oct 20 10:00:22 2005 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86EA216A41F for ; Thu, 20 Oct 2005 10:00:22 +0000 (GMT) (envelope-from past@ebs.gr) Received: from fly.ebs.gr (fly.ebs.gr [62.103.84.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D59F43D68 for ; Thu, 20 Oct 2005 10:00:20 +0000 (GMT) (envelope-from past@ebs.gr) Received: from ebs.gr (root@hal.ebs.gr [10.1.1.2]) by fly.ebs.gr (8.12.9p1/8.12.9) with ESMTP id j9KA0I9V050280; Thu, 20 Oct 2005 13:00:18 +0300 (EEST) (envelope-from past@ebs.gr) Received: from [10.1.1.158] (pc158.ebs.gr [10.1.1.158]) by ebs.gr (8.13.3/8.12.11) with ESMTP id j9KA0V8Z006024; Thu, 20 Oct 2005 13:00:32 +0300 (EEST) (envelope-from past@ebs.gr) Message-ID: <43576A9D.1050209@ebs.gr> Date: Thu, 20 Oct 2005 12:59:57 +0300 From: Panagiotis Astithas Organization: EBS Ltd. User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051008) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Maksim Yevmenkin 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> In-Reply-To: <4356D12F.7000006@savvis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org Subject: Re: [RFC] rc.d integration for the bluetooth subsystem X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2005 10:00:22 -0000 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