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