From owner-freebsd-rc@FreeBSD.ORG Mon Oct 31 11:02:37 2005 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA3AB16A41F for ; Mon, 31 Oct 2005 11:02:37 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01D6643D6A for ; Mon, 31 Oct 2005 11:02:26 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j9VB2QYV009058 for ; Mon, 31 Oct 2005 11:02:26 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j9VB2PPJ009052 for freebsd-rc@freebsd.org; Mon, 31 Oct 2005 11:02:25 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 31 Oct 2005 11:02:25 GMT Message-Id: <200510311102.j9VB2PPJ009052@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-rc@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2005 11:02:38 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2005/02/10] conf/77340 rc awk used in /etc/rc.d/nsswitch when not a 1 problem total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/06/30] conf/68525 rc Loader's verbose boot mode has rc.d/local o [2004/07/07] conf/68745 rc /etc/rc.d/devfs runs after ntpd so links o [2005/05/14] kern/81006 rc ipnat not working with tunnel interfaces 3 problems total. From owner-freebsd-rc@FreeBSD.ORG Tue Nov 1 16:36:30 2005 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C965E16A41F for ; Tue, 1 Nov 2005 16:36:30 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7C0543D79 for ; Tue, 1 Nov 2005 16:36:17 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id jA1Ga6F1057103; Tue, 1 Nov 2005 19:36:06 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id jA1Ga5t4057102; Tue, 1 Nov 2005 19:36:05 +0300 (MSK) (envelope-from yar) Date: Tue, 1 Nov 2005 19:36:05 +0300 From: Yar Tikhiy To: Dirk Engling Message-ID: <20051101163605.GA56709@comp.chem.msu.su> References: <20051026051029.GA32620@comp.chem.msu.su> <20051029090008.J74189@erdgeist.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051029090008.J74189@erdgeist.org> User-Agent: Mutt/1.5.9i Cc: freebsd-rc@freebsd.org Subject: Re: A fix for `restart' X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2005 16:36:30 -0000 On Sat, Oct 29, 2005 at 09:17:51AM +0200, Dirk Engling wrote: > > On Wed, 26 Oct 2005, Yar Tikhiy wrote: > > >Would you mind testing the following patch to /etc/rc.subr > >that should remedy problems with `restart', e.g., as found > >for /etc/rc.d/jail? It is safe as it doesn't affect other > >commans and hence it won't disrupt your boot sequence :-) > >I'm just concerned about possible side-effects for restart > >I might have overlooked. The test case of scripts taking > >additional arguments besides the command is the most intriguing. > > I included that patch and successfully ran it for a week and dozends of > restarts. For me it looks like the patch solves the problem I had and > stands little chance of making things worse than before. > > Thanks a lot. Is there any chance that this bug fix will find its way into > 6.0RELEASE? It is great news that my patch worked for you! However, patches affecting everyone through rc.subr should be tested by much wider audience than the two of us can provide. Hence I'm afraid it is too late to push the patch into 6.0-RELEASE, especially given that there will be no 6.0-RC2. I'd like to merge the patch to RELENG_6 soon after the release is out, so stay tuned :-) -- Yar From owner-freebsd-rc@FreeBSD.ORG Tue Nov 1 21:51:08 2005 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 119C016A41F; Tue, 1 Nov 2005 21:51:08 +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 1587143D49; Tue, 1 Nov 2005 21:51:06 +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 jA1Lp5J21368; Tue, 1 Nov 2005 16:51:05 -0500 Message-ID: <4367E346.4080106@savvis.net> Date: Tue, 01 Nov 2005 13:51:02 -0800 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-bluetooth@freebsd.org, freebsd-rc@freebsd.org 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> <4357CEA5.1000308@savvis.net> <4357D9E2.6010701@ebs.gr> In-Reply-To: <4357D9E2.6010701@ebs.gr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Panagiotis Astithas Subject: Re: [RFC] rc.d integration for the bluetooth subsystem X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2005 21:51:08 -0000 All, 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 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 example. it should be copied to /etc/rc.conf.d/bluetooth.$dev and then defaults can be adjusted. once again if there is no /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. thanks, max From owner-freebsd-rc@FreeBSD.ORG Tue Nov 1 22:46:01 2005 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95FD816A41F; Tue, 1 Nov 2005 22:46:01 +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 2417D43D53; Tue, 1 Nov 2005 22:45:58 +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 jA1MjsMv003503; Tue, 1 Nov 2005 14:45:54 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id jA1MjsqR003501; Tue, 1 Nov 2005 14:45:54 -0800 Date: Tue, 1 Nov 2005 14:45:54 -0800 From: Brooks Davis To: Maksim Yevmenkin Message-ID: <20051101224554.GA20543@odin.ac.hmc.edu> References: <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> <4357CEA5.1000308@savvis.net> <4357D9E2.6010701@ebs.gr> <4367E346.4080106@savvis.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline In-Reply-To: <4367E346.4080106@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: freebsd-bluetooth@freebsd.org, freebsd-rc@freebsd.org, Panagiotis Astithas Subject: Re: [RFC] rc.d integration for the bluetooth subsystem X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2005 22:46:01 -0000 --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 01, 2005 at 01:51:02PM -0800, Maksim Yevmenkin wrote: > All, >=20 > please find the first draft of bluetooth rc.d scripts located at >=20 > http://people.freebsd.org/~emax/bluetooth-rc.diff.txt >=20 > this patch adds >=20 > 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=20 > arrival and departure events. the script also supports _optional_ per=20 > device configuration. per device configuration is stored in=20 > /etc/rc.conf.d/bluetooth.$dev file, where $dev is the driver name of the= =20 > device, i.e. ubt0, sio4, btccc1 >=20 > 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=20 > defaults can be adjusted. once again if there is no=20 > /etc/rc.conf.d/bluetooth.$dev script then reasonable defaults will be use= d. >=20 > 3) required changes to /etc/Makefile, /etc/mtree/BSD.root.dist, etc. to= =20 > hook up new scripts to the build. >=20 > i'd appreciate any feedback you might have. >=20 > 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 configure them. :) I'm a bit dubious about the bluetooth.device.sample idea. What if you used an /etc/defaults/bluetooth.device that you 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. -- 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 --0F1p//8PRICkK4MW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDZ/AhXY6L6fI4GtQRAu5rAKDeHNCbLUonvnH84o7AqdYJuNi8gACfd3uL 8+eW2ZVz/OA+3yXwl0h6oL8= =QWor -----END PGP SIGNATURE----- --0F1p//8PRICkK4MW-- From owner-freebsd-rc@FreeBSD.ORG Wed Nov 2 00:00:28 2005 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 617EB16A41F; Wed, 2 Nov 2005 00:00:28 +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 6A80D43D5E; Wed, 2 Nov 2005 00:00:18 +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 jA200CJ25064; Tue, 1 Nov 2005 19:00:16 -0500 Message-ID: <4368018A.8040403@savvis.net> Date: Tue, 01 Nov 2005 16:00:10 -0800 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis References: <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> <4357CEA5.1000308@savvis.net> <4357D9E2.6010701@ebs.gr> <4367E346.4080106@savvis.net> <20051101224554.GA20543@odin.ac.hmc.edu> In-Reply-To: <20051101224554.GA20543@odin.ac.hmc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org, freebsd-rc@freebsd.org Subject: Re: [RFC] rc.d integration for the bluetooth subsystem X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2005 00:00:28 -0000 Brooks, >> 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 >> 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 >> example. it should be copied to /etc/rc.conf.d/bluetooth.$dev and >> then defaults can be adjusted. once again if there is no >> /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 i will try to do my best :) > configure them. :) I'm a bit dubious about the bluetooth.device.sample > idea. What if you used an /etc/defaults/bluetooth.device that you this is *exactly* what i'm concern about too :) but i obviously do not understand rc.d subsystem very well. hence i sent this to freebsd-rc@ in a hope to find better solution. > 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. my original idea goes like this: 1) the system must support more then one bluetooth device connected at a time. this is _not_ a typical setup, but i'd rather not introduce any limitations; 2) it should be possible to configure each device in a slightly different manner. for example, i'd like to be able to assign unique device name to each device, etc. 3) each bluetooth device has few netgraph nodes associated with it (and only it), i.e. driver node, hci and l2cap. so i'd like to be able to set, say, hci and l2cap debug levels for one device, but not for another. 4) in the future, it may be desirable to run some services bound to specific device. such services should be started when device is connected and stopped when device is disconnected (note: this is not done yet). again, i could not find the clean way to express configuration for multiple devices using just /etc/rc.conf. i'm _not_ saying it does not exists :) i thought of a couple other ways, i.e - have all non-default parameters for a device in one line, i.e. ${dev}_bluetooth_config=".." i did not like this one because hccontrol(8) and other bluetooth tools do not support more than one command at a time, i.e. its not possible to run "hccontrol -n ubt0hci cmd1 param1 cmd2 param2". changing hccontrol(8) to support this kind of syntax is somewhat tricky, because commands may have optional parameters. - have all non-default parameters appear on a separate lines, i.e. ${dev}_bluetooth_local_name="..." ${dev}_bluetooth_hci_debug_level="..." i did not like this one because it seemed like to much clutter in /etc/rc.conf. also variable names are far too long to my taste. right now, there are few parameters for each device that can be tweaked. in the future more may be desired. i also wanted to make configuration as simple as possible. ideal case if the defaults work for 90+% of the time. so, i started looking at /etc/rc.subr and specifically at load_rc_config(). the nice thing about it that it will automatically source /etc/defaults/rc.conf, /etc/rc.conf and then /etc/rc.conf.d/$_command (if exists). so the rest is quite simple: 1) /etc/rc.d/bluetooth has hardwired "reasonable" defaults. if there is only going to be one bluetooth device connected to the system then there is no need to create /etc/rc.conf.d/bluetooth.foo file. in fact, even if multiple devices are connected, but it is not required to configure them differently then it should work too. 2) if someone wants to tweak parameters then all he/she needs to do is to copy /etc/rc.conf.d/bluetooth.device.sample into /etc/rc.conf.d/bluetooth.ubt0 (ubt0 is a first bluetooth usb device) and edit it. i liked having all device specific parameters in one file under /etc/rc.conf.d. it kinda looks flexible. on the other hand, it makes system more linux-like :) depending on your taste it may or may not be a good thing :) may be i did not make it clear, but /etc/rc.conf.d/bluetooth.device.sample does _not_ contain defaults. it is just an _example_ of what can be put into etc/rc.conf.d/bluetooth.foo file. bluetooth.device.sample does not have to live in /etc/rc.conf.d and it does not have to be called bluetooth.device.sample. may be i should move it into /usr/share/examples/netgraph/bluetooth. may be i should rename it. or may be both. thanks, max From owner-freebsd-rc@FreeBSD.ORG Wed Nov 2 11:17:34 2005 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3836C16A420; Wed, 2 Nov 2005 11:17:34 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A06043D4C; Wed, 2 Nov 2005 11:17:25 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id jA2BHAUj006084; Wed, 2 Nov 2005 14:17:10 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id jA2BH9s1006083; Wed, 2 Nov 2005 14:17:09 +0300 (MSK) (envelope-from yar) Date: Wed, 2 Nov 2005 14:17:09 +0300 From: Yar Tikhiy To: Maksim Yevmenkin Message-ID: <20051102111709.GD2465@comp.chem.msu.su> References: <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> <4357CEA5.1000308@savvis.net> <4357D9E2.6010701@ebs.gr> <4367E346.4080106@savvis.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4367E346.4080106@savvis.net> User-Agent: Mutt/1.5.9i Cc: freebsd-bluetooth@freebsd.org, freebsd-rc@freebsd.org, Panagiotis Astithas Subject: Re: [RFC] rc.d integration for the bluetooth subsystem X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2005 11:17:34 -0000 On Tue, Nov 01, 2005 at 01:51:02PM -0800, Maksim Yevmenkin wrote: > All, > > 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 > 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 > example. it should be copied to /etc/rc.conf.d/bluetooth.$dev and then > defaults can be adjusted. once again if there is no > /etc/rc.conf.d/bluetooth.$dev script then reasonable defaults will be used. My concern is about putting things not related directly to system startup driven by rc(8) in /etc/rc.d and /etc/rc.conf.d directories. Perhaps it would be better to still use rc.subr as a source of great subroutines, but place the bluetooth scripts and configs in their own directories -- rc.subr should support this. -- Yar From owner-freebsd-rc@FreeBSD.ORG Wed Nov 2 16:13:42 2005 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56F3F16A41F; Wed, 2 Nov 2005 16:13:42 +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 E350543D45; Wed, 2 Nov 2005 16:13:41 +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 jA2GDBxd008901; Wed, 2 Nov 2005 08:13:11 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id jA2GDB1J008900; Wed, 2 Nov 2005 08:13:11 -0800 Date: Wed, 2 Nov 2005 08:13:11 -0800 From: Brooks Davis To: Yar Tikhiy Message-ID: <20051102161311.GA8499@odin.ac.hmc.edu> References: <4353DBBC.2000508@savvis.net> <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> <20051102111709.GD2465@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gKMricLos+KVdGMg" Content-Disposition: inline In-Reply-To: <20051102111709.GD2465@comp.chem.msu.su> 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: freebsd-bluetooth@freebsd.org, freebsd-rc@freebsd.org, Panagiotis Astithas Subject: Re: [RFC] rc.d integration for the bluetooth subsystem X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2005 16:13:42 -0000 --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 02, 2005 at 02:17:09PM +0300, Yar Tikhiy wrote: > On Tue, Nov 01, 2005 at 01:51:02PM -0800, Maksim Yevmenkin wrote: > > All, > >=20 > > please find the first draft of bluetooth rc.d scripts located at > >=20 > > http://people.freebsd.org/~emax/bluetooth-rc.diff.txt > >=20 > > this patch adds > >=20 > > 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= =20 > > arrival and departure events. the script also supports _optional_ per= =20 > > device configuration. per device configuration is stored in=20 > > /etc/rc.conf.d/bluetooth.$dev file, where $dev is the driver name of th= e=20 > > device, i.e. ubt0, sio4, btccc1 > >=20 > > 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= =20 > > defaults can be adjusted. once again if there is no=20 > > /etc/rc.conf.d/bluetooth.$dev script then reasonable defaults will be u= sed. >=20 > My concern is about putting things not related directly to system > startup driven by rc(8) in /etc/rc.d and /etc/rc.conf.d directories. > Perhaps it would be better to still use rc.subr as a source of great > subroutines, but place the bluetooth scripts and configs in their > own directories -- rc.subr should support this. I don't disagree, but we've already got three scripts like this in /etc/rc.d (dhclient, power_profile, and wpa_supplicant) so I don't think it's a big deal. IMO, the conf files are find (though I don't like the idea of a .sample in /etc/rc.conf.d). There is some argument for moving the scripts to another directory though. I'm not sure what we'd call it though. -- 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 --gKMricLos+KVdGMg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDaOWWXY6L6fI4GtQRAhK7AJ40RFpmZnOqZTIeWZzPZPxOLLnbegCg2foV ZnETu3oKuyS/y/5wC4Pz0ew= =SvHf -----END PGP SIGNATURE----- --gKMricLos+KVdGMg-- From owner-freebsd-rc@FreeBSD.ORG Wed Nov 2 16:20:53 2005 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@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: freebsd-bluetooth@freebsd.org, freebsd-rc@freebsd.org Subject: Re: [RFC] rc.d integration for the bluetooth subsystem X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." 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-- From owner-freebsd-rc@FreeBSD.ORG Wed Nov 2 18:20:39 2005 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAC9F16A420; Wed, 2 Nov 2005 18:20:39 +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 4294D43D46; Wed, 2 Nov 2005 18:20:39 +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 jA2IKOJ17925; Wed, 2 Nov 2005 13:20:27 -0500 Message-ID: <43690365.60909@savvis.net> Date: Wed, 02 Nov 2005 10:20:21 -0800 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis References: <4353DBBC.2000508@savvis.net> <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> <20051102111709.GD2465@comp.chem.msu.su> <20051102161311.GA8499@odin.ac.hmc.edu> In-Reply-To: <20051102161311.GA8499@odin.ac.hmc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org, freebsd-rc@freebsd.org, Panagiotis Astithas Subject: Re: [RFC] rc.d integration for the bluetooth subsystem X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2005 18:20:40 -0000 Brooks Davis wrote: > On Wed, Nov 02, 2005 at 02:17:09PM +0300, Yar Tikhiy wrote: > >>On Tue, Nov 01, 2005 at 01:51:02PM -0800, Maksim Yevmenkin wrote: >> >>>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 >>>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 >>>example. it should be copied to /etc/rc.conf.d/bluetooth.$dev and then >>>defaults can be adjusted. once again if there is no >>>/etc/rc.conf.d/bluetooth.$dev script then reasonable defaults will be used. >> >>My concern is about putting things not related directly to system >>startup driven by rc(8) in /etc/rc.d and /etc/rc.conf.d directories. >>Perhaps it would be better to still use rc.subr as a source of great >>subroutines, but place the bluetooth scripts and configs in their >>own directories -- rc.subr should support this. > > I don't disagree, but we've already got three scripts like this in > /etc/rc.d (dhclient, power_profile, and wpa_supplicant) so I don't think > it's a big deal. IMO, the conf files are find (though I don't like the this was another thing that i was worried about too :) however, as you pointed out, rc.d already has few 'nostart' scripts. keep in mind that even though /etc/rc.d/bluetooth has 'nostart' keyword it is still possible to execute it by hand, i.e. '/etc/rc.d/bluetooth restart ubt0' and it will work. this way you could restart bluetooth stack without unplugging the device. i imagine one might want to tweak config and the restart the stack. imo, /etc/rc.d is a good place for bluetooth script. > idea of a .sample in /etc/rc.conf.d). There is some argument for moving > the scripts to another directory though. I'm not sure what we'd call > it though. ok, let me re-phrase the question then do you think that having multiple config files under /etc/rc.conf.d is a good idea? do you think that other subsystem might benefit from similar (to bluetooth) config style or bluetooth will be the only subsystem that uses it? i'd really hate to introduce somewhat new config style just for bluetooth. i really do not want people whine about it and ask why they cant put things into /etc/rc.conf (where the rest of config is). freebsd is not linux. adding or changing things should produce benefits that would overweight potential complains from users, imo. thanks, max From owner-freebsd-rc@FreeBSD.ORG Wed Nov 2 18:38:38 2005 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2FD716A420; Wed, 2 Nov 2005 18:38:38 +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 C932343D48; Wed, 2 Nov 2005 18:38:36 +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 jA2IcO9V004592; Wed, 2 Nov 2005 20:38:24 +0200 (EET) (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 jA2IcYVm025811; Wed, 2 Nov 2005 20:38:34 +0200 (EET) (envelope-from past@ebs.gr) Message-ID: <43690768.9010708@ebs.gr> Date: Wed, 02 Nov 2005 20:37:28 +0200 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: <4353DBBC.2000508@savvis.net> <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> <20051102111709.GD2465@comp.chem.msu.su> <20051102161311.GA8499@odin.ac.hmc.edu> <43690365.60909@savvis.net> In-Reply-To: <43690365.60909@savvis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-rc@freebsd.org, freebsd-bluetooth@freebsd.org Subject: Re: [RFC] rc.d integration for the bluetooth subsystem X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2005 18:38:39 -0000 Maksim Yevmenkin wrote: > Brooks Davis wrote: > >> On Wed, Nov 02, 2005 at 02:17:09PM +0300, Yar Tikhiy wrote: >> >>> On Tue, Nov 01, 2005 at 01:51:02PM -0800, Maksim Yevmenkin wrote: >>> >>>> 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 >>>> 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 >>>> example. it should be copied to /etc/rc.conf.d/bluetooth.$dev and >>>> then defaults can be adjusted. once again if there is no >>>> /etc/rc.conf.d/bluetooth.$dev script then reasonable defaults will >>>> be used. >>> >>> >>> My concern is about putting things not related directly to system >>> startup driven by rc(8) in /etc/rc.d and /etc/rc.conf.d directories. >>> Perhaps it would be better to still use rc.subr as a source of great >>> subroutines, but place the bluetooth scripts and configs in their >>> own directories -- rc.subr should support this. >> >> >> I don't disagree, but we've already got three scripts like this in >> /etc/rc.d (dhclient, power_profile, and wpa_supplicant) so I don't think >> it's a big deal. IMO, the conf files are find (though I don't like the > > > this was another thing that i was worried about too :) however, as you > pointed out, rc.d already has few 'nostart' scripts. keep in mind that > even though /etc/rc.d/bluetooth has 'nostart' keyword it is still > possible to execute it by hand, i.e. '/etc/rc.d/bluetooth restart ubt0' > and it will work. this way you could restart bluetooth stack without > unplugging the device. i imagine one might want to tweak config and the > restart the stack. imo, /etc/rc.d is a good place for bluetooth script. > >> idea of a .sample in /etc/rc.conf.d). There is some argument for moving >> the scripts to another directory though. I'm not sure what we'd call >> it though. > > > ok, let me re-phrase the question then > > do you think that having multiple config files under /etc/rc.conf.d is a > good idea? > > do you think that other subsystem might benefit from similar (to > bluetooth) config style or bluetooth will be the only subsystem that > uses it? > > i'd really hate to introduce somewhat new config style just for > bluetooth. i really do not want people whine about it and ask why they > cant put things into /etc/rc.conf (where the rest of config is). freebsd > is not linux. adding or changing things should produce benefits that > would overweight potential complains from users, imo. A somewhat similar situation exists with the /etc/start_if.$dev scripts. They contain per-device configuration, but they are dumped in /etc. If there is discomfort about creating rc.conf.d just for the bluetooth subsystem, perhaps /etc could be chosen instead. Another way might be to use a single /etc/bluetooth.conf along the lines of /etc/wpa_supplicant.conf (one section per device), but this requires more parsing work for the /etc/rc.d/bluetooth script. I'm not sure if it is worth it. FWIW, I really like the bluetooth.device.sample contents. Cheers, Panagiotis From owner-freebsd-rc@FreeBSD.ORG Wed Nov 2 19:07:12 2005 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D16116A41F; Wed, 2 Nov 2005 19:07:12 +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 9B39343D45; Wed, 2 Nov 2005 19:07:11 +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 jA2J6t1n007369; Wed, 2 Nov 2005 11:06:55 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id jA2J6tlJ007368; Wed, 2 Nov 2005 11:06:55 -0800 Date: Wed, 2 Nov 2005 11:06:55 -0800 From: Brooks Davis To: Maksim Yevmenkin Message-ID: <20051102190655.GA3961@odin.ac.hmc.edu> References: <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> <20051102111709.GD2465@comp.chem.msu.su> <20051102161311.GA8499@odin.ac.hmc.edu> <43690365.60909@savvis.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline In-Reply-To: <43690365.60909@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: freebsd-rc@freebsd.org, freebsd-bluetooth@freebsd.org, Panagiotis Astithas Subject: Re: [RFC] rc.d integration for the bluetooth subsystem X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2005 19:07:12 -0000 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 02, 2005 at 10:20:21AM -0800, Maksim Yevmenkin wrote: > Brooks Davis wrote: > >On Wed, Nov 02, 2005 at 02:17:09PM +0300, Yar Tikhiy wrote: > > > >>On Tue, Nov 01, 2005 at 01:51:02PM -0800, Maksim Yevmenkin wrote: > >> > >>>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= =20 > >>>arrival and departure events. the script also supports _optional_ per= =20 > >>>device configuration. per device configuration is stored in=20 > >>>/etc/rc.conf.d/bluetooth.$dev file, where $dev is the driver name of t= he=20 > >>>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= =20 > >>>defaults can be adjusted. once again if there is no=20 > >>>/etc/rc.conf.d/bluetooth.$dev script then reasonable defaults will be= =20 > >>>used. > >> > >>My concern is about putting things not related directly to system > >>startup driven by rc(8) in /etc/rc.d and /etc/rc.conf.d directories. > >>Perhaps it would be better to still use rc.subr as a source of great > >>subroutines, but place the bluetooth scripts and configs in their > >>own directories -- rc.subr should support this. > > > >I don't disagree, but we've already got three scripts like this in > >/etc/rc.d (dhclient, power_profile, and wpa_supplicant) so I don't think > >it's a big deal. IMO, the conf files are find (though I don't like the >=20 > this was another thing that i was worried about too :) however, as you=20 > pointed out, rc.d already has few 'nostart' scripts. keep in mind that=20 > even though /etc/rc.d/bluetooth has 'nostart' keyword it is still=20 > possible to execute it by hand, i.e. '/etc/rc.d/bluetooth restart ubt0'= =20 > and it will work. this way you could restart bluetooth stack without=20 > unplugging the device. i imagine one might want to tweak config and the= =20 > restart the stack. imo, /etc/rc.d is a good place for bluetooth script. > > >idea of a .sample in /etc/rc.conf.d). There is some argument for moving > >the scripts to another directory though. I'm not sure what we'd call > >it though. >=20 > ok, let me re-phrase the question then >=20 > do you think that having multiple config files under /etc/rc.conf.d is a= =20 > good idea? The one problem with this is that it breaks the model that rc.conf.d contains files with contents that could live in in /etc/rc.conf. That may not be a sufficiently large problem to worry about though. If it is an issue an /etc/bluetooth.d could be a solution. > do you think that other subsystem might benefit from similar (to=20 > bluetooth) config style or bluetooth will be the only subsystem that=20 > uses it? I've been thinking a little bit about hostapd and it needs multiple config files. For it I was thinking of of creating an /etc/hostapd.conf.d directory. > i'd really hate to introduce somewhat new config style just for=20 > bluetooth. i really do not want people whine about it and ask why they=20 > cant put things into /etc/rc.conf (where the rest of config is). freebsd= =20 > is not linux. adding or changing things should produce benefits that=20 > would overweight potential complains from users, imo. If the concern is about people complaining about /etc/rc.conf not working, then you have no choice but to use variables with the device name in them. There's no other way to do it and keep those semantics. As I say above, I'm not sure how important it is, but from this perspective it's pretty critical. One interesting option might be to (ab)use the fact that config files are scripts and modify the sample file slightly to call a function (probably defined in an /etc/bluetooth.subr) that converts from the set of variables you are using now to a set of ugly, but per device named variables. i.e. you'd add something like the following to the end of the config file: =2E /etc/bluetooth.subr convert_bluetooth_vars $dev convert_bluetooth vars would then set the device variables and undefine the non-specific ones. That would preserve the clean file-per-device syntax and the ability to set everything in /etc/rc.conf. -- 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 --4Ckj6UjgE2iN1+kY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDaQ5OXY6L6fI4GtQRAtgqAJ9+tGZMmzUdJSuVRpjJi4ksYaY8aQCgvY4y VhyLINo14LlHBV3YF8z0obY= =qD3i -----END PGP SIGNATURE----- --4Ckj6UjgE2iN1+kY-- From owner-freebsd-rc@FreeBSD.ORG Wed Nov 2 21:39:49 2005 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC18C16A41F; Wed, 2 Nov 2005 21:39:49 +0000 (GMT) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C2F543D46; Wed, 2 Nov 2005 21:39:49 +0000 (GMT) (envelope-from lyndon@orthanc.ca) Received: from peregrin.orthanc.ca (d64-180-189-53.bchsia.telus.net [64.180.189.53]) (authenticated bits=0) by orthanc.ca (8.13.3/8.13.3) with ESMTP id jA2Ldjdd014948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Nov 2005 14:39:46 -0700 (MST) (envelope-from lyndon@orthanc.ca) Received: from [127.0.0.1] (localhost [127.0.0.1]) by peregrin.orthanc.ca (8.13.5.Beta0/8.13.5.Beta0) with ESMTP id jA2LdXSV013662; Wed, 2 Nov 2005 13:39:33 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: <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> <20051102162052.GB8499@odin.ac.hmc.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <154616DE-63E8-4C96-9D56-55A0FFD3CB88@orthanc.ca> Content-Transfer-Encoding: 7bit From: Lyndon Nerenberg Date: Wed, 2 Nov 2005 13:39:31 -0800 To: freebsd-bluetooth@freebsd.org, freebsd-rc@freebsd.org X-Mailer: Apple Mail (2.734) X-Spam-Status: No, score=0.8 required=5.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO, RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on orthanc.ca Cc: Subject: Re: [RFC] rc.d integration for the bluetooth subsystem X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2005 21:39:50 -0000 On Nov 2, 2005, at 8:20 AM, Brooks Davis wrote: >> ${dev}_bluetooth_config=".." >> >> i did not like this one because hccontrol(8) and other bluetooth >> tools >> do not support more than one command at a time, i.e. its not >> possible to >> run "hccontrol -n ubt0hci cmd1 param1 cmd2 param2". changing >> hccontrol(8) to support this kind of syntax is somewhat tricky, >> because >> commands may have optional parameters. >> >> - have all non-default parameters appear on a separate lines, i.e. >> >> ${dev}_bluetooth_local_name="..." >> ${dev}_bluetooth_hci_debug_level="..." I would prefer these variable names take the form bluetooth_${dev} _foo, or even better, btconf_${dev}_foo. That way all the bluetooth config entries group together by device when rc.conf is kept sorted by variable name. (This also follows the ifconfig_{$if} naming convention.) --lyndon From owner-freebsd-rc@FreeBSD.ORG Thu Nov 3 19:34:54 2005 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A28C616A41F; Thu, 3 Nov 2005 19:34:54 +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 EE9E543D53; Thu, 3 Nov 2005 19:34:53 +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 jA3JYZJ16328; Thu, 3 Nov 2005 14:34:42 -0500 Message-ID: <436A6649.7000602@savvis.net> Date: Thu, 03 Nov 2005 11:34:33 -0800 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis References: <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> <20051102111709.GD2465@comp.chem.msu.su> <20051102161311.GA8499@odin.ac.hmc.edu> <43690365.60909@savvis.net> <20051102190655.GA3961@odin.ac.hmc.edu> In-Reply-To: <20051102190655.GA3961@odin.ac.hmc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org, freebsd-rc@freebsd.org, Panagiotis Astithas Subject: Re: [RFC] rc.d integration for the bluetooth subsystem X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2005 19:34:54 -0000 Brooks Davis wrote: [...] >>>> My concern is about putting things not related directly to >>>> system startup driven by rc(8) in /etc/rc.d and /etc/rc.conf.d >>>> directories. Perhaps it would be better to still use rc.subr as >>>> a source of great subroutines, but place the bluetooth scripts >>>> and configs in their own directories -- rc.subr should support >>>> this. >>> >>> I don't disagree, but we've already got three scripts like this >>> in /etc/rc.d (dhclient, power_profile, and wpa_supplicant) so I >>> don't think it's a big deal. IMO, the conf files are find >>> (though I don't like the >> >> this was another thing that i was worried about too :) however, as >> you pointed out, rc.d already has few 'nostart' scripts. keep in >> mind that even though /etc/rc.d/bluetooth has 'nostart' keyword it >> is still possible to execute it by hand, i.e. '/etc/rc.d/bluetooth >> restart ubt0' and it will work. this way you could restart >> bluetooth stack without unplugging the device. i imagine one might >> want to tweak config and the restart the stack. imo, /etc/rc.d is a >> good place for bluetooth script. >> >>> idea of a .sample in /etc/rc.conf.d). There is some argument for >>> moving the scripts to another directory though. I'm not sure >>> what we'd call it though. >> >> ok, let me re-phrase the question then >> >> do you think that having multiple config files under /etc/rc.conf.d >> is a good idea? > > The one problem with this is that it breaks the model that rc.conf.d > contains files with contents that could live in in /etc/rc.conf. > That may not be a sufficiently large problem to worry about though. > If it is an issue an /etc/bluetooth.d could be a solution. well, may be. is it really required to create configuration directory under /etc for every subsystem? do you think this is better then, say, have multiple files under /etc/rc.conf.d? >> do you think that other subsystem might benefit from similar (to >> bluetooth) config style or bluetooth will be the only subsystem >> that uses it? > > I've been thinking a little bit about hostapd and it needs multiple > config files. For it I was thinking of of creating an > /etc/hostapd.conf.d directory. please see my comment above. >> i'd really hate to introduce somewhat new config style just for >> bluetooth. i really do not want people whine about it and ask why >> they cant put things into /etc/rc.conf (where the rest of config >> is). freebsd is not linux. adding or changing things should produce >> benefits that would overweight potential complains from users, imo. > > If the concern is about people complaining about /etc/rc.conf not > working, then you have no choice but to use variables with the device > name in them. There's no other way to do it and keep those > semantics. As I say above, I'm not sure how important it is, but from > this perspective it's pretty critical. i think it is. another thing i'm worried about is sysinstall(8). right now it puts stuff into /etc/rc.conf. maybe its better to have things in /etc/rc.conf so it easier to modify sysinstall(8)? > One interesting option might be to (ab)use the fact that config files > are scripts and modify the sample file slightly to call a function > (probably defined in an /etc/bluetooth.subr) that converts from the > set of variables you are using now to a set of ugly, but per device > named variables. i.e. you'd add something like the following to the > end of the config file: > > . /etc/bluetooth.subr convert_bluetooth_vars $dev > > convert_bluetooth vars would then set the device variables and > undefine the non-specific ones. That would preserve the clean > file-per-device syntax and the ability to set everything in > /etc/rc.conf. now thats an interesting idea. how about adding export_rc_config() function that would export all variables from the given file with the given namespace prefix (please see below)? also how about moving _optional_ per-device configuration files under /etc/bluetooth? # # export_rc_config # Source in the configuration file and export all variables from # the file with the namespace prefix # export_rc_config() { _file=$1 _namespace=$2 if [ -z "$_file" -o -z "$_namespace" ]; then err 3 'USAGE: export_rc_config file namespace' fi { while read line do case $line in \#*) continue ;; *) _var=`expr "$line" : "^\([a-zA-Z0-9_]*\)="` _val=`expr "$line" : "^.*=\(.*\)"` if [ -z "$_var" -o -z "$_val" ]; then continue; fi _exported_var="$_namespace$_var" eval $_exported_var=$_val ;; esac done } < $_file return 0 } thanks, max From owner-freebsd-rc@FreeBSD.ORG Thu Nov 3 20:33:01 2005 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B3E716A41F; Thu, 3 Nov 2005 20:33:01 +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 13A5443D48; Thu, 3 Nov 2005 20:33:00 +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 jA3KWHL6010773; Thu, 3 Nov 2005 12:32:17 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id jA3KWHF0010772; Thu, 3 Nov 2005 12:32:17 -0800 Date: Thu, 3 Nov 2005 12:32:17 -0800 From: Brooks Davis To: Maksim Yevmenkin Message-ID: <20051103203217.GA30685@odin.ac.hmc.edu> References: <4356D12F.7000006@savvis.net> <43576A9D.1050209@ebs.gr> <4357CEA5.1000308@savvis.net> <4357D9E2.6010701@ebs.gr> <4367E346.4080106@savvis.net> <20051102111709.GD2465@comp.chem.msu.su> <20051102161311.GA8499@odin.ac.hmc.edu> <43690365.60909@savvis.net> <20051102190655.GA3961@odin.ac.hmc.edu> <436A6649.7000602@savvis.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline In-Reply-To: <436A6649.7000602@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: freebsd-rc@freebsd.org, freebsd-bluetooth@freebsd.org, Panagiotis Astithas Subject: Re: [RFC] rc.d integration for the bluetooth subsystem X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2005 20:33:01 -0000 --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 03, 2005 at 11:34:33AM -0800, Maksim Yevmenkin wrote: > Brooks Davis wrote: >=20 > [...] >=20 > >>>>My concern is about putting things not related directly to > >>>>system startup driven by rc(8) in /etc/rc.d and /etc/rc.conf.d > >>>>directories. Perhaps it would be better to still use rc.subr as > >>>>a source of great subroutines, but place the bluetooth scripts > >>>>and configs in their own directories -- rc.subr should support > >>>>this. > >>> > >>>I don't disagree, but we've already got three scripts like this > >>>in /etc/rc.d (dhclient, power_profile, and wpa_supplicant) so I > >>>don't think it's a big deal. IMO, the conf files are find > >>>(though I don't like the > >> > >>this was another thing that i was worried about too :) however, as > >>you pointed out, rc.d already has few 'nostart' scripts. keep in > >>mind that even though /etc/rc.d/bluetooth has 'nostart' keyword it > >>is still possible to execute it by hand, i.e. '/etc/rc.d/bluetooth > >>restart ubt0' and it will work. this way you could restart > >>bluetooth stack without unplugging the device. i imagine one might > >>want to tweak config and the restart the stack. imo, /etc/rc.d is a > >>good place for bluetooth script. > >> > >>>idea of a .sample in /etc/rc.conf.d). There is some argument for > >>>moving the scripts to another directory though. I'm not sure > >>>what we'd call it though. > >> > >>ok, let me re-phrase the question then > >> > >>do you think that having multiple config files under /etc/rc.conf.d > >>is a good idea? > > > >The one problem with this is that it breaks the model that rc.conf.d=20 > >contains files with contents that could live in in /etc/rc.conf. > >That may not be a sufficiently large problem to worry about though. > >If it is an issue an /etc/bluetooth.d could be a solution. >=20 > well, may be. is it really required to create configuration directory=20 > under /etc for every subsystem? do you think this is better then, say,=20 > have multiple files under /etc/rc.conf.d? > > >>do you think that other subsystem might benefit from similar (to=20 > >>bluetooth) config style or bluetooth will be the only subsystem > >>that uses it? > > > >I've been thinking a little bit about hostapd and it needs multiple=20 > >config files. For it I was thinking of of creating an=20 > >/etc/hostapd.conf.d directory. >=20 > please see my comment above. For hostapd, I think a new directory is required (or at least a good idea) because it won't include a bunch of rc.conf variables. The bluetooth stuff is a bit more vague because it's mostly rc.conf like. > >>i'd really hate to introduce somewhat new config style just for=20 > >>bluetooth. i really do not want people whine about it and ask why > >>they cant put things into /etc/rc.conf (where the rest of config > >>is). freebsd is not linux. adding or changing things should produce > >>benefits that would overweight potential complains from users, imo. > > > >If the concern is about people complaining about /etc/rc.conf not=20 > >working, then you have no choice but to use variables with the device > > name in them. There's no other way to do it and keep those > >semantics. As I say above, I'm not sure how important it is, but from > >this perspective it's pretty critical. >=20 > i think it is. another thing i'm worried about is sysinstall(8). right=20 > now it puts stuff into /etc/rc.conf. maybe its better to have things in= =20 > /etc/rc.conf so it easier to modify sysinstall(8)? >=20 > >One interesting option might be to (ab)use the fact that config files > > are scripts and modify the sample file slightly to call a function=20 > >(probably defined in an /etc/bluetooth.subr) that converts from the > >set of variables you are using now to a set of ugly, but per device > >named variables. i.e. you'd add something like the following to the > >end of the config file: > > > >. /etc/bluetooth.subr convert_bluetooth_vars $dev > > > >convert_bluetooth vars would then set the device variables and > >undefine the non-specific ones. That would preserve the clean > >file-per-device syntax and the ability to set everything in > >/etc/rc.conf. >=20 > now thats an interesting idea. how about adding export_rc_config()=20 > function that would export all variables from the given file with the=20 > given namespace prefix (please see below)? also how about moving=20 > _optional_ per-device configuration files under /etc/bluetooth? >=20 > # > # export_rc_config > # Source in the configuration file and export all variables from > # the file with the namespace prefix > # > export_rc_config() > { > _file=3D$1 > _namespace=3D$2 >=20 > if [ -z "$_file" -o -z "$_namespace" ]; then > err 3 'USAGE: export_rc_config file namespace' > fi >=20 > { while read line > do > case $line in > \#*) > continue > ;; >=20 > *) > _var=3D`expr "$line" : "^\([a-zA-Z0-9_]*\)=3D"` > _val=3D`expr "$line" : "^.*=3D\(.*\)"` >=20 > if [ -z "$_var" -o -z "$_val" ]; then > continue; > fi >=20 > _exported_var=3D"$_namespace$_var" > eval $_exported_var=3D$_val > ;; > esac > done } < $_file >=20 > return 0 > } If you moved the files under /etc/bluetooth, I think this would be OK, because that would make the fact that they aren't scripts more clear. If you intermixed them with other things, I'd be a bit concerned about people thinking they were scripts like normal rc.conf config files. -- 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 --3V7upXqbjpZ4EhLz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDanPQXY6L6fI4GtQRAhDIAJ4wi0PhBei3zXFpRRFeIPyz4nZjMQCg4NTl MSJYJXA8hFzrBWWC91BO9B0= =GOwS -----END PGP SIGNATURE----- --3V7upXqbjpZ4EhLz-- From owner-freebsd-rc@FreeBSD.ORG Fri Nov 4 22:27:08 2005 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C601716A41F; Fri, 4 Nov 2005 22:27:08 +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 56B9043D5C; Fri, 4 Nov 2005 22:27:06 +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 jA4MQuJ17318; Fri, 4 Nov 2005 17:26:56 -0500 Message-ID: <436BE02D.2020404@savvis.net> Date: Fri, 04 Nov 2005 14:26:53 -0800 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-bluetooth@freebsd.org, freebsd-rc@freebsd.org References: <4356D12F.7000006@savvis.net> <43576A9D.1050209@ebs.gr> <4357CEA5.1000308@savvis.net> <4357D9E2.6010701@ebs.gr> <4367E346.4080106@savvis.net> <20051102111709.GD2465@comp.chem.msu.su> <20051102161311.GA8499@odin.ac.hmc.edu> <43690365.60909@savvis.net> <20051102190655.GA3961@odin.ac.hmc.edu> <436A6649.7000602@savvis.net> <20051103203217.GA30685@odin.ac.hmc.edu> In-Reply-To: <20051103203217.GA30685@odin.ac.hmc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Panagiotis Astithas Subject: Re: [RFC] rc.d integration for the bluetooth subsystem X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2005 22:27:09 -0000 All, please find next revision of bluetooth-rc stuff at http://people.freebsd.org/~emax/bluetooth-rc-1.diff.txt in this revision i have moved all bluetooth configuration files under /etc/bluetooth. bluetooth.device.sample is now called 'default.conf' and file that contain device specific overrides called '$dev.conf' (i.e. 'ubt0.conf'). so, '/etc/rc.d/bluetooth start $dev' does the following 1) sets hardwired defaults (for backward compatibility) 2) reads up /etc/bluetooth/default.conf (if any) 3) reads up /etc/bluetooth/$dev.conf (if any) 4) starts the stack even though /etc/bluetooth/{default,$dev}.conf are not exactly shell scripts they are still kinda like shell scripts :) these files should follow sh(1) syntax to set the variable, comments etc. the parser in bluetooth_read_conf() is very simple and value of a variable is still used in sh(1) eval. so one must be careful when editing these files. is this looks like something? i also could write bluetooth.device.conf(5) man page that describes the parameters as well as the syntax of the files. thanks, max From owner-freebsd-rc@FreeBSD.ORG Sat Nov 5 11:35:11 2005 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D89516A41F; Sat, 5 Nov 2005 11:35:11 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79C9B43D46; Sat, 5 Nov 2005 11:35:10 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id jA5BZ411014625; Sat, 5 Nov 2005 14:35:04 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id jA5BZ3TU014624; Sat, 5 Nov 2005 14:35:03 +0300 (MSK) (envelope-from yar) Date: Sat, 5 Nov 2005 14:35:03 +0300 From: Yar Tikhiy To: Maksim Yevmenkin Message-ID: <20051105113503.GA13863@comp.chem.msu.su> References: <4357CEA5.1000308@savvis.net> <4357D9E2.6010701@ebs.gr> <4367E346.4080106@savvis.net> <20051102111709.GD2465@comp.chem.msu.su> <20051102161311.GA8499@odin.ac.hmc.edu> <43690365.60909@savvis.net> <20051102190655.GA3961@odin.ac.hmc.edu> <436A6649.7000602@savvis.net> <20051103203217.GA30685@odin.ac.hmc.edu> <436BE02D.2020404@savvis.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <436BE02D.2020404@savvis.net> User-Agent: Mutt/1.5.9i Cc: freebsd-bluetooth@freebsd.org, freebsd-rc@freebsd.org, Panagiotis Astithas Subject: Re: [RFC] rc.d integration for the bluetooth subsystem X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2005 11:35:11 -0000 On Fri, Nov 04, 2005 at 02:26:53PM -0800, Maksim Yevmenkin wrote: > All, > > please find next revision of bluetooth-rc stuff at > > http://people.freebsd.org/~emax/bluetooth-rc-1.diff.txt > > in this revision i have moved all bluetooth configuration files under > /etc/bluetooth. bluetooth.device.sample is now called 'default.conf' and > file that contain device specific overrides called '$dev.conf' (i.e. > 'ubt0.conf'). > > so, '/etc/rc.d/bluetooth start $dev' does the following > > 1) sets hardwired defaults (for backward compatibility) > > 2) reads up /etc/bluetooth/default.conf (if any) > > 3) reads up /etc/bluetooth/$dev.conf (if any) > > 4) starts the stack > > even though /etc/bluetooth/{default,$dev}.conf are not exactly shell > scripts they are still kinda like shell scripts :) these files should > follow sh(1) syntax to set the variable, comments etc. > > the parser in bluetooth_read_conf() is very simple and value of a > variable is still used in sh(1) eval. so one must be careful when > editing these files. What about simplifying the inner parser code even more: case "$_line" in ''|\#*) ;; *) if expr "$_line" : "[a-zA-Z0-9_]*="; then eval "${_namespace}${_line}" else ${logger} "Unable to parse line \"$_line\" in $_file" return 1 fi ;; esac BTW, couldn't just err() or warn() be used instead of ${logger}? And AFAIK stdin to a while loop can be redirected w/o enclosing the loop in braces. -- Yar