[RFC] rc.d integration for the bluetooth subsystem

[Maksim Yevmenkin]

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