From owner-freebsd-bluetooth@FreeBSD.ORG Mon Oct 17 22:03:08 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 4022F16A41F for ; Mon, 17 Oct 2005 22:03:08 +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 1F83E43D49 for ; Mon, 17 Oct 2005 22:03:06 +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 j9HM319V039807; Tue, 18 Oct 2005 01:03:01 +0300 (EEST) (envelope-from past@ebs.gr) Received: from [10.1.1.200] (pptp.ebs.gr [10.1.1.200]) by ebs.gr (8.13.3/8.12.11) with ESMTP id j9HM36oe054229; Tue, 18 Oct 2005 01:03:10 +0300 (EEST) (envelope-from past@ebs.gr) Message-ID: <43541F79.6040008@ebs.gr> Date: Tue, 18 Oct 2005 01:02:33 +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> In-Reply-To: <4353DBBC.2000508@savvis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: vova@fbsd.ru, 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: Mon, 17 Oct 2005 22:03:08 -0000 Maksim Yevmenkin wrote: > Panagiotis, > > it appears i have missed your original email :( not a big problem - i > have found it in the archive. please read my comments inline. > >>> I've been playing with integrating the bluetooth subsystem into our >>> rc.d infrastructure and I'd like to submit the results of my >>> efforts for review. My testing has been centered around my USB >>> bluetooth dongle and I know that it works, but I suppose other >>> bluetooth devices should work as well. I have taken the existing >>> rc.bluetooth script (that is not installed by default) and >>> converted it to rc.d, renaming it as 'bluetooth'. I also added a >>> couple of other scripts for hcsecd and sdpd, that are started from >>> bluetooth, but can also function independently, id so desired. >>> Finally I have added a devd configuration file that makes sure the >>> bluetooth script gets started on insertion and removal of the USB >>> dongle. > > > that is great. thanks for doing the work! it seems we have been working > on this in parallel :) about a week ago i have committed (into -current) > hcsecd(8) and sdpd(8) rc.d scripts. they are very similar to what you > have done. please see > > http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.d/hcsecd > > http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.d/sdpd > > http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/defaults/rc.conf > > for more details. Excellent! I missed your commits, although I try to keep up with cvs-src from time to time. You obviously did a better job with these two scripts than me and I appreciate it. >>> With these changes, when I plug in my USB bluetooth dongle, all the >>> necessary initialization happens behind the scenes and I can start >>> using my bluetooth peripherals right away. When I unplug the dongle >>> all the services stop and the necessary shutdown operations are >>> performed on the bluetooth stack. There is still some work left, >>> like specifying different flags for sdpd & hcsecd, but the defaults >>> work fine. > > > that sounds just fine. once again - do not worry about hcsecd(8) and > sdpd(8) scripts anymore - they are done. > >>> In order to test this stuff you have to: >>> >>> - copy bluetooth, hcsecd and sdpd into /etc/rc.d - copy ubt.conf >>> into /usr/local/etc/devd (creating it if necessary), or add its >>> contents to /etc/devd.conf - add a line in /etc/rc.conf with: >>> bluetooth_enable="YES" >>> >>> In an eventual merge into the base system the devd configuration >>> should be merged into /etc/devd.conf and /etc/defaults/rc.conf >>> should contain the following line instead: bluetooth_enable="NO" >>> >>> I'd appreciate any comments you may have. > > > devd(8) configuration (ubt.conf) looks fine. i can merge this info > devd.conf for you. hcsecd(8) and sdpd(8) already committed into > -current. i have also created bluetooth section in the > /etc/defaults/rc.conf file. > > i have few comments about my original rc.bluetooth script. > > 1) it probably should not load any kernel modules. the problem is that > when one (or more) bluetooth kernel modules compiled into the kernel the > kldstat(8) check may fail. this has to do with the way kldstat(8) prints > the results and the way rc.bluetooth grep's through them. > > 2) original rc.bluetooth is very rigid. things like device name, device > class, etc. are hardwired into the script. so i'd like to have a bit of > flexibility here, i.e. ability to specify per device > > - device name (change_local_name) > > - device class (write_class_of_device) > > - should device be "visible"/discoverable by default (write_scan_enable) > > - should device request authentication (write_authentication_enable) > > - should device use encryption (write_encryption_enable) > > - should device request role switch (write_node_role_switch) > > and maybe few others. > > 3) i'd like to have some way to execute a few hccontrol(8) commands > after default setup was done. perhaps this could be done with some sort > of bluetooth.local rc.d script that will be executed after main script. > by default it should be empty. another way to do it is to have something > along the bluetooth_extra_commands variable in rc.conf. Thanks for the comments. I understand your concerns and share some of your reservations regarding the rc.bluetooth script (or my rc.d-fied version of it). Nevertheless, I feel that the lack of (some version of) it in the base system, complicates unnecessary the use of the bluetooth stack. I do agree that the goals you describe should be pursued. I would ask you though to consider adding even this imperfect, rigid version in the meantime, while we plan how we can improve on it further. After all devd must execute something, right? :-) I'd like to think some more about your general plan. I might find some time to help. Thanks, Panagiotis