Date: Thu, 3 Nov 2005 12:32:17 -0800 From: Brooks Davis <brooks@one-eyed-alien.net> To: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> Cc: Brooks Davis <brooks@one-eyed-alien.net>, Yar Tikhiy <yar@comp.chem.msu.su>, freebsd-rc@freebsd.org, freebsd-bluetooth@freebsd.org Subject: Re: [RFC] rc.d integration for the bluetooth subsystem Message-ID: <20051103203217.GA30685@odin.ac.hmc.edu> In-Reply-To: <436A6649.7000602@savvis.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051103203217.GA30685>