From owner-freebsd-bluetooth@FreeBSD.ORG Thu Oct 20 17:06:55 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 82A2216A41F for ; Thu, 20 Oct 2005 17:06:55 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from ismybrain.com (ismybrain.com [64.246.42.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 151CD43D5A for ; Thu, 20 Oct 2005 17:06:54 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from [10.254.186.111] (localhost.localdomain [127.0.0.1]) by ismybrain.com (8.11.6/8.11.6) with ESMTP id j9KH6lJ06297; Thu, 20 Oct 2005 13:06:47 -0400 Message-ID: <4357CEA5.1000308@savvis.net> Date: Thu, 20 Oct 2005 10:06:45 -0700 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Panagiotis Astithas 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> In-Reply-To: <43576A9D.1050209@ebs.gr> 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 17:06:55 -0000 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