[RFC] rc.d integration for the bluetooth subsystem

[Brooks Davis]

On Thu, Nov 03, 2005 at 11:34:33AM -0800, Maksim Yevmenkin wrote:
> 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.

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

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

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-bluetooth/attachments/20051103/1d30bacf/attachment.bin