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--