From owner-freebsd-bluetooth@FreeBSD.ORG Thu Nov 3 19:34:54 2005 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A28C616A41F; Thu, 3 Nov 2005 19:34:54 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from ismybrain.com (ismybrain.com [64.246.42.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE9E543D53; Thu, 3 Nov 2005 19:34:53 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from [10.254.186.111] (localhost.localdomain [127.0.0.1]) by ismybrain.com (8.11.6/8.11.6) with ESMTP id jA3JYZJ16328; Thu, 3 Nov 2005 14:34:42 -0500 Message-ID: <436A6649.7000602@savvis.net> Date: Thu, 03 Nov 2005 11:34:33 -0800 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis 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> In-Reply-To: <20051102190655.GA3961@odin.ac.hmc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org, Yar Tikhiy , freebsd-rc@freebsd.org Subject: Re: [RFC] rc.d integration for the bluetooth subsystem X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2005 19:34:54 -0000 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