From owner-freebsd-bluetooth@FreeBSD.ORG Wed Nov 2 16:20:53 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 5FFDB16A428; Wed, 2 Nov 2005 16:20:53 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA49943D48; Wed, 2 Nov 2005 16:20:52 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id jA2GKqp6009947; Wed, 2 Nov 2005 08:20:52 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id jA2GKqHj009946; Wed, 2 Nov 2005 08:20:52 -0800 Date: Wed, 2 Nov 2005 08:20:52 -0800 From: Brooks Davis To: Maksim Yevmenkin Message-ID: <20051102162052.GB8499@odin.ac.hmc.edu> References: <43541F79.6040008@ebs.gr> <43554BCE.7090309@savvis.net> <4355FD0C.2090702@ebs.gr> <4356D12F.7000006@savvis.net> <43576A9D.1050209@ebs.gr> <4357CEA5.1000308@savvis.net> <4357D9E2.6010701@ebs.gr> <4367E346.4080106@savvis.net> <20051101224554.GA20543@odin.ac.hmc.edu> <4368018A.8040403@savvis.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1LKvkjL3sHcu1TtY" Content-Disposition: inline In-Reply-To: <4368018A.8040403@savvis.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: Brooks Davis , freebsd-bluetooth@freebsd.org, freebsd-rc@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: Wed, 02 Nov 2005 16:20:53 -0000 --1LKvkjL3sHcu1TtY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 01, 2005 at 04:00:10PM -0800, Maksim Yevmenkin wrote: > Brooks, >=20 > >>please find the first draft of bluetooth rc.d scripts located at > >> > >>http://people.freebsd.org/~emax/bluetooth-rc.diff.txt > >> > >>this patch adds > >> > >>1) /etc/rc.d/bluetooth script that will be used to start and stop=20 > >>bluetooth devices. it will be called by devd(8) in response to > >>device arrival and departure events. the script also supports > >>_optional_ per device configuration. per device configuration is > >>stored in /etc/rc.conf.d/bluetooth.$dev file, where $dev is the > >>driver name of the device, i.e. ubt0, sio4, btccc1 > >> > >>2) /etc/rc.conf.d/bluetooth.device.sample script. this is just an=20 > >>example. it should be copied to /etc/rc.conf.d/bluetooth.$dev and > >>then defaults can be adjusted. once again if there is no=20 > >>/etc/rc.conf.d/bluetooth.$dev script then reasonable defaults will > >>be used. > >> > >>3) required changes to /etc/Makefile, /etc/mtree/BSD.root.dist, > >>etc. to hook up new scripts to the build. > >> > >>i'd appreciate any feedback you might have. > >> > >>this work is inspired by the patches from Panagiotis Astithas. > > > >This looks like a powerful framework, I may need to find some bluetooth > >devices to play with if you're going to make it relatively easy to >=20 > i will try to do my best :) >=20 > >configure them. :) I'm a bit dubious about the bluetooth.device.sample > >idea. What if you used an /etc/defaults/bluetooth.device that you >=20 > this is *exactly* what i'm concern about too :) but i obviously do not=20 > understand rc.d subsystem very well. hence i sent this to freebsd-rc@ in= =20 > a hope to find better solution. >=20 > >pulled in to set the defaults instead? It could contain the current > >example code, but set all the variables do define the defaults. I think > >that would be more in keeping with current practice. Adding rc.conf.d > >to mtree is probably a good idea regardless though. >=20 > my original idea goes like this: >=20 > 1) the system must support more then one bluetooth device connected at a= =20 > time. this is _not_ a typical setup, but i'd rather not introduce any=20 > limitations; >=20 > 2) it should be possible to configure each device in a slightly=20 > different manner. for example, i'd like to be able to assign unique=20 > device name to each device, etc. >=20 > 3) each bluetooth device has few netgraph nodes associated with it (and= =20 > only it), i.e. driver node, hci and l2cap. so i'd like to be able to=20 > set, say, hci and l2cap debug levels for one device, but not for another. >=20 > 4) in the future, it may be desirable to run some services bound to=20 > specific device. such services should be started when device is=20 > connected and stopped when device is disconnected (note: this is not=20 > done yet). >=20 > again, i could not find the clean way to express configuration for=20 > multiple devices using just /etc/rc.conf. i'm _not_ saying it does not=20 > exists :) i thought of a couple other ways, i.e >=20 > - have all non-default parameters for a device in one line, i.e. >=20 > ${dev}_bluetooth_config=3D".." >=20 > i did not like this one because hccontrol(8) and other bluetooth tools=20 > do not support more than one command at a time, i.e. its not possible to= =20 > run "hccontrol -n ubt0hci cmd1 param1 cmd2 param2". changing=20 > hccontrol(8) to support this kind of syntax is somewhat tricky, because= =20 > commands may have optional parameters. >=20 > - have all non-default parameters appear on a separate lines, i.e. >=20 > ${dev}_bluetooth_local_name=3D"..." > ${dev}_bluetooth_hci_debug_level=3D"..." >=20 > i did not like this one because it seemed like to much clutter in=20 > /etc/rc.conf. also variable names are far too long to my taste. >=20 > right now, there are few parameters for each device that can be tweaked.= =20 > in the future more may be desired. i also wanted to make configuration=20 > as simple as possible. ideal case if the defaults work for 90+% of the ti= me. >=20 > so, i started looking at /etc/rc.subr and specifically at=20 > load_rc_config(). the nice thing about it that it will automatically=20 > source /etc/defaults/rc.conf, /etc/rc.conf and then=20 > /etc/rc.conf.d/$_command (if exists). so the rest is quite simple: >=20 > 1) /etc/rc.d/bluetooth has hardwired "reasonable" defaults. if there is= =20 > only going to be one bluetooth device connected to the system then there= =20 > is no need to create /etc/rc.conf.d/bluetooth.foo file. in fact, even if= =20 > multiple devices are connected, but it is not required to configure them= =20 > differently then it should work too. >=20 > 2) if someone wants to tweak parameters then all he/she needs to do is=20 > to copy /etc/rc.conf.d/bluetooth.device.sample into=20 > /etc/rc.conf.d/bluetooth.ubt0 (ubt0 is a first bluetooth usb device) and= =20 > edit it. >=20 > i liked having all device specific parameters in one file under=20 > /etc/rc.conf.d. it kinda looks flexible. on the other hand, it makes=20 > system more linux-like :) depending on your taste it may or may not be a= =20 > good thing :) >=20 > may be i did not make it clear, but=20 > /etc/rc.conf.d/bluetooth.device.sample does _not_ contain defaults. it=20 > is just an _example_ of what can be put into etc/rc.conf.d/bluetooth.foo= =20 > file. bluetooth.device.sample does not have to live in /etc/rc.conf.d=20 > and it does not have to be called bluetooth.device.sample. may be i=20 > should move it into /usr/share/examples/netgraph/bluetooth. may be i=20 > should rename it. or may be both. I'm fine with the config files in /etc/rc.conf.d. Since the file doesn't contain defaults, /usr/share/examples seems like a fine place to me, though examples/etc/rc.conf.d/ might be a better place. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --1LKvkjL3sHcu1TtY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDaOdjXY6L6fI4GtQRAphQAJ0e0iDyTWCrtU5xxtn3UqgwJ/KvDQCggHET nzmUGiIO/+KvhCQFV9aLlcc= =lurY -----END PGP SIGNATURE----- --1LKvkjL3sHcu1TtY--