[RFC] rc.d integration for the bluetooth subsystem

[Brooks Davis]

On Tue, Nov 01, 2005 at 04:00:10PM -0800, Maksim Yevmenkin wrote:
> Brooks,
> 
> >>please find the first draft of bluetooth rc.d scripts located at
> >>
> >>http://people.freebsd.org/~emax/bluetooth-rc.diff.txt
> >>
> >>this patch adds
> >>
> >>1) /etc/rc.d/bluetooth script that will be used to start and stop 
> >>bluetooth devices. it will be called by devd(8) in response to
> >>device arrival and departure events. the script also supports
> >>_optional_ per device configuration. per device configuration is
> >>stored in /etc/rc.conf.d/bluetooth.$dev file, where $dev is the
> >>driver name of the device, i.e. ubt0, sio4, btccc1
> >>
> >>2) /etc/rc.conf.d/bluetooth.device.sample script. this is just an 
> >>example. it should be copied to /etc/rc.conf.d/bluetooth.$dev and
> >>then defaults can be adjusted. once again if there is no 
> >>/etc/rc.conf.d/bluetooth.$dev script then reasonable defaults will
> >>be used.
> >>
> >>3) required changes to /etc/Makefile, /etc/mtree/BSD.root.dist,
> >>etc. to hook up new scripts to the build.
> >>
> >>i'd appreciate any feedback you might have.
> >>
> >>this work is inspired by the patches from Panagiotis Astithas.
> >
> >This looks like a powerful framework, I may need to find some bluetooth
> >devices to play with if you're going to make it relatively easy to
> 
> i will try to do my best :)
> 
> >configure them. :) I'm a bit dubious about the bluetooth.device.sample
> >idea.  What if you used an /etc/defaults/bluetooth.device that you
> 
> this is *exactly* what i'm concern about too :) but i obviously do not 
> understand rc.d subsystem very well. hence i sent this to freebsd-rc@ in 
> a hope to find better solution.
> 
> >pulled in to set the defaults instead?  It could contain the current
> >example code, but set all the variables do define the defaults.  I think
> >that would be more in keeping with current practice.  Adding rc.conf.d
> >to mtree is probably a good idea regardless though.
> 
> my original idea goes like this:
> 
> 1) the system must support more then one bluetooth device connected at a 
> time. this is _not_ a typical setup, but i'd rather not introduce any 
> limitations;
> 
> 2) it should be possible to configure each device in a slightly 
> different manner. for example, i'd like to be able to assign unique 
> device name to each device, etc.
> 
> 3) each bluetooth device has few netgraph nodes associated with it (and 
> only it), i.e. driver node, hci and l2cap. so i'd like to be able to 
> set, say, hci and l2cap debug levels for one device, but not for another.
> 
> 4) in the future, it may be desirable to run some services bound to 
> specific device. such services should be started when device is 
> connected and stopped when device is disconnected (note: this is not 
> done yet).
> 
> again, i could not find the clean way to express configuration for 
> multiple devices using just /etc/rc.conf. i'm _not_ saying it does not 
> exists :) i thought of a couple other ways, i.e
> 
> - have all non-default parameters for a device in one line, i.e.
> 
>   ${dev}_bluetooth_config=".."
> 
> i did not like this one because hccontrol(8) and other bluetooth tools 
> do not support more than one command at a time, i.e. its not possible to 
> run "hccontrol -n ubt0hci cmd1 param1 cmd2 param2". changing 
> hccontrol(8) to support this kind of syntax is somewhat tricky, because 
> commands may have optional parameters.
> 
> - have all non-default parameters appear on a separate lines, i.e.
> 
>   ${dev}_bluetooth_local_name="..."
>   ${dev}_bluetooth_hci_debug_level="..."
> 
> i did not like this one because it seemed like to much clutter in 
> /etc/rc.conf. also variable names are far too long to my taste.
> 
> right now, there are few parameters for each device that can be tweaked. 
> in the future more may be desired. i also wanted to make configuration 
> as simple as possible. ideal case if the defaults work for 90+% of the time.
> 
> so, i started looking at /etc/rc.subr and specifically at 
> load_rc_config(). the nice thing about it that it will automatically 
> source /etc/defaults/rc.conf, /etc/rc.conf and then 
> /etc/rc.conf.d/$_command (if exists). so the rest is quite simple:
> 
> 1) /etc/rc.d/bluetooth has hardwired "reasonable" defaults. if there is 
> only going to be one bluetooth device connected to the system then there 
> is no need to create /etc/rc.conf.d/bluetooth.foo file. in fact, even if 
> multiple devices are connected, but it is not required to configure them 
> differently then it should work too.
> 
> 2) if someone wants to tweak parameters then all he/she needs to do is 
> to copy /etc/rc.conf.d/bluetooth.device.sample into 
> /etc/rc.conf.d/bluetooth.ubt0 (ubt0 is a first bluetooth usb device) and 
> edit it.
> 
> i liked having all device specific parameters in one file under 
> /etc/rc.conf.d. it kinda looks flexible. on the other hand, it makes 
> system more linux-like :) depending on your taste it may or may not be a 
> good thing :)
> 
> may be i did not make it clear, but 
> /etc/rc.conf.d/bluetooth.device.sample does _not_ contain defaults. it 
> is just an _example_ of what can be put into etc/rc.conf.d/bluetooth.foo 
> file. bluetooth.device.sample does not have to live in /etc/rc.conf.d 
> and it does not have to be called bluetooth.device.sample. may be i 
> should move it into /usr/share/examples/netgraph/bluetooth. may be i 
> should rename it. or may be both.

I'm fine with the config files in /etc/rc.conf.d.  Since the file
doesn't contain defaults, /usr/share/examples seems like a fine place to
me, though examples/etc/rc.conf.d/ might be a better place.

-- 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/20051102/ece899aa/attachment.bin