Re: [RFC] rc.d integration for the bluetooth subsystem

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] rc.d integration for the bluetooth subsystem

Maksim Yevmenkin
All,

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.

thanks,
max
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] rc.d integration for the bluetooth subsystem

Brooks Davis
On Tue, Nov 01, 2005 at 01:51:02PM -0800, Maksim Yevmenkin wrote:

> All,
>
> 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
configure them. :) I'm a bit dubious about the bluetooth.device.sample
idea.  What if you used an /etc/defaults/bluetooth.device that you
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.

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

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] rc.d integration for the bluetooth subsystem

Maksim Yevmenkin
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.

thanks,
max
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-rc
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] rc.d integration for the bluetooth subsystem

Yar Tikhiy-2
In reply to this post by Maksim Yevmenkin
On Tue, Nov 01, 2005 at 01:51:02PM -0800, Maksim Yevmenkin wrote:

> All,
>
> 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.

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.

--
Yar
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] rc.d integration for the bluetooth subsystem

Brooks Davis
On Wed, Nov 02, 2005 at 02:17:09PM +0300, Yar Tikhiy wrote:

> On Tue, Nov 01, 2005 at 01:51:02PM -0800, Maksim Yevmenkin wrote:
> > All,
> >
> > 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.
>
> 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
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.

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

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] rc.d integration for the bluetooth subsystem

Brooks Davis
In reply to this post by Maksim Yevmenkin
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

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] rc.d integration for the bluetooth subsystem

Maksim Yevmenkin
In reply to this post by Brooks Davis
Brooks Davis wrote:

> On Wed, Nov 02, 2005 at 02:17:09PM +0300, Yar Tikhiy wrote:
>
>>On Tue, Nov 01, 2005 at 01:51:02PM -0800, Maksim Yevmenkin wrote:
>>
>>>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.
>>
>>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?

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'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.

thanks,
max
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] rc.d integration for the bluetooth subsystem

Panagiotis Astithas
Maksim Yevmenkin wrote:

> Brooks Davis wrote:
>
>> On Wed, Nov 02, 2005 at 02:17:09PM +0300, Yar Tikhiy wrote:
>>
>>> On Tue, Nov 01, 2005 at 01:51:02PM -0800, Maksim Yevmenkin wrote:
>>>
>>>> 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.
>>>
>>>
>>> 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?
>
> 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'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.

A somewhat similar situation exists with the /etc/start_if.$dev scripts.
They contain per-device configuration, but they are dumped in /etc. If
there is discomfort about creating rc.conf.d just for the bluetooth
subsystem, perhaps /etc could be chosen instead.

Another way might be to use a single /etc/bluetooth.conf along the lines
of /etc/wpa_supplicant.conf (one section per device), but this requires
more parsing work for the /etc/rc.d/bluetooth script. I'm not sure if it
is worth it.

FWIW, I really like the bluetooth.device.sample contents.

Cheers,
Panagiotis
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] rc.d integration for the bluetooth subsystem

Brooks Davis
In reply to this post by Maksim Yevmenkin
On Wed, Nov 02, 2005 at 10:20:21AM -0800, Maksim Yevmenkin wrote:

> Brooks Davis wrote:
> >On Wed, Nov 02, 2005 at 02:17:09PM +0300, Yar Tikhiy wrote:
> >
> >>On Tue, Nov 01, 2005 at 01:51:02PM -0800, Maksim Yevmenkin wrote:
> >>
> >>>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.
> >>
> >>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.

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

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

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.

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

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] rc.d integration for the bluetooth subsystem

Lyndon Nerenberg (VE6BBM/VE7TFX)
In reply to this post by Brooks Davis

On Nov 2, 2005, at 8:20 AM, Brooks Davis wrote:

>>   ${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 would prefer these variable names take the form bluetooth_${dev}
_foo, or even better, btconf_${dev}_foo.  That way all the bluetooth  
config entries group together by device when rc.conf is kept sorted  
by variable name. (This also follows the ifconfig_{$if} naming  
convention.)

--lyndon
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] rc.d integration for the bluetooth subsystem

Maksim Yevmenkin
In reply to this post by Brooks Davis
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

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-rc
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [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

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] rc.d integration for the bluetooth subsystem

Maksim Yevmenkin
All,

please find next revision of bluetooth-rc stuff at

http://people.freebsd.org/~emax/bluetooth-rc-1.diff.txt

in this revision i have moved all bluetooth configuration files under
/etc/bluetooth. bluetooth.device.sample is now called 'default.conf' and
file that contain device specific overrides called '$dev.conf' (i.e.
'ubt0.conf').

so, '/etc/rc.d/bluetooth start $dev' does the following

1) sets hardwired defaults (for backward compatibility)

2) reads up /etc/bluetooth/default.conf (if any)

3) reads up /etc/bluetooth/$dev.conf (if any)

4) starts the stack

even though /etc/bluetooth/{default,$dev}.conf are not exactly shell
scripts they are still kinda like shell scripts :) these files should
follow sh(1) syntax to set the variable, comments etc.

the parser in bluetooth_read_conf() is very simple and value of a
variable is still used in sh(1) eval. so one must be careful when
editing these files.

is this looks like something? i also could write
bluetooth.device.conf(5) man page that describes the parameters as well
as the syntax of the files.

thanks,
max
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] rc.d integration for the bluetooth subsystem

Yar Tikhiy-2
On Fri, Nov 04, 2005 at 02:26:53PM -0800, Maksim Yevmenkin wrote:

> All,
>
> please find next revision of bluetooth-rc stuff at
>
> http://people.freebsd.org/~emax/bluetooth-rc-1.diff.txt
>
> in this revision i have moved all bluetooth configuration files under
> /etc/bluetooth. bluetooth.device.sample is now called 'default.conf' and
> file that contain device specific overrides called '$dev.conf' (i.e.
> 'ubt0.conf').
>
> so, '/etc/rc.d/bluetooth start $dev' does the following
>
> 1) sets hardwired defaults (for backward compatibility)
>
> 2) reads up /etc/bluetooth/default.conf (if any)
>
> 3) reads up /etc/bluetooth/$dev.conf (if any)
>
> 4) starts the stack
>
> even though /etc/bluetooth/{default,$dev}.conf are not exactly shell
> scripts they are still kinda like shell scripts :) these files should
> follow sh(1) syntax to set the variable, comments etc.
>
> the parser in bluetooth_read_conf() is very simple and value of a
> variable is still used in sh(1) eval. so one must be careful when
> editing these files.

What about simplifying the inner parser code even more:

        case "$_line" in
        ''|\#*)
                ;;
        *)
                if expr "$_line" : "[a-zA-Z0-9_]*="; then
                        eval "${_namespace}${_line}"
                else
                        ${logger} "Unable to parse line \"$_line\" in $_file"
                        return 1
                fi
                ;;
        esac

BTW, couldn't just err() or warn() be used instead of ${logger}?
And AFAIK stdin to a while loop can be redirected w/o enclosing
the loop in braces.

--
Yar
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-rc
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] rc.d integration for the bluetooth subsystem

Maksim Yevmenkin
Yar Tikhiy wrote:

> On Fri, Nov 04, 2005 at 02:26:53PM -0800, Maksim Yevmenkin wrote:
>
>>All,
>>
>>please find next revision of bluetooth-rc stuff at
>>
>>http://people.freebsd.org/~emax/bluetooth-rc-1.diff.txt
>>
>>in this revision i have moved all bluetooth configuration files under
>>/etc/bluetooth. bluetooth.device.sample is now called 'default.conf' and
>>file that contain device specific overrides called '$dev.conf' (i.e.
>>'ubt0.conf').
>>
>>so, '/etc/rc.d/bluetooth start $dev' does the following
>>
>>1) sets hardwired defaults (for backward compatibility)
>>
>>2) reads up /etc/bluetooth/default.conf (if any)
>>
>>3) reads up /etc/bluetooth/$dev.conf (if any)
>>
>>4) starts the stack
>>
>>even though /etc/bluetooth/{default,$dev}.conf are not exactly shell
>>scripts they are still kinda like shell scripts :) these files should
>>follow sh(1) syntax to set the variable, comments etc.
>>
>>the parser in bluetooth_read_conf() is very simple and value of a
>>variable is still used in sh(1) eval. so one must be careful when
>>editing these files.
>
> What about simplifying the inner parser code even more:
>
> case "$_line" in
> ''|\#*)
> ;;
> *)
> if expr "$_line" : "[a-zA-Z0-9_]*="; then
> eval "${_namespace}${_line}"
> else
> ${logger} "Unable to parse line \"$_line\" in $_file"
> return 1
> fi
> ;;
> esac

sure. only need to

if expr "$_line" : "[a-zA-Z0-9_]*=" > /dev/null 2>&1 ; then
...
fi

i do not really have any objection to this. since i already pass the
value through eval i might as well pass the entire line.

> BTW, couldn't just err() or warn() be used instead of ${logger}?

i guess they could

> And AFAIK stdin to a while loop can be redirected w/o enclosing
> the loop in braces.

sure, but it looked more clear (to me anyway) this way :)

so does this look like something?

http://people.freebsd.org/~emax/bluetooth-rc-2.diff.txt

any other comments, suggestions, objections? please speak.

thanks,
max
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] rc.d integration for the bluetooth subsystem

Brooks Davis
In reply to this post by Maksim Yevmenkin
On Fri, Nov 04, 2005 at 02:26:53PM -0800, Maksim Yevmenkin wrote:

> All,
>
> please find next revision of bluetooth-rc stuff at
>
> http://people.freebsd.org/~emax/bluetooth-rc-1.diff.txt
>
> in this revision i have moved all bluetooth configuration files under
> /etc/bluetooth. bluetooth.device.sample is now called 'default.conf' and
> file that contain device specific overrides called '$dev.conf' (i.e.
> 'ubt0.conf').
>
> so, '/etc/rc.d/bluetooth start $dev' does the following
>
> 1) sets hardwired defaults (for backward compatibility)
>
> 2) reads up /etc/bluetooth/default.conf (if any)
I think /etc/defaults/bluetooth.device.conf might be better since we do
have a defined location of default files and this will discourge people
from messing with them.

> 3) reads up /etc/bluetooth/$dev.conf (if any)
>
> 4) starts the stack
>
> even though /etc/bluetooth/{default,$dev}.conf are not exactly shell
> scripts they are still kinda like shell scripts :) these files should
> follow sh(1) syntax to set the variable, comments etc.
>
> the parser in bluetooth_read_conf() is very simple and value of a
> variable is still used in sh(1) eval. so one must be careful when
> editing these files.
>
> is this looks like something? i also could write
> bluetooth.device.conf(5) man page that describes the parameters as well
> as the syntax of the files.
A bluetooth.device.conf(5) man page would be a good idea, though the
example file is quite good.

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

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] rc.d integration for the bluetooth subsystem

Maksim Yevmenkin
Brooks,

>>please find next revision of bluetooth-rc stuff at
>>
>>http://people.freebsd.org/~emax/bluetooth-rc-1.diff.txt
>>
>>in this revision i have moved all bluetooth configuration files under
>>/etc/bluetooth. bluetooth.device.sample is now called 'default.conf' and
>>file that contain device specific overrides called '$dev.conf' (i.e.
>>'ubt0.conf').
>>
>>so, '/etc/rc.d/bluetooth start $dev' does the following
>>
>>1) sets hardwired defaults (for backward compatibility)
>>
>>2) reads up /etc/bluetooth/default.conf (if any)
>
> I think /etc/defaults/bluetooth.device.conf might be better since we do
> have a defined location of default files and this will discourge people
> from messing with them.

that is fine with me. i'm sorry this is taking so long :) now the last
question: should we keep device specific files under /etc/bluetooth or
just under /etc? right now i have devfs.rules, pccard.conf,
periodic.conf and rc.conf under /etc/defaults. overrides for these go
into /etc.

another alternative (which probably no one is going to like) is to use
/etc/bluetooth/defaults/device.conf (defaults) and
/etc/bluetooth/$dev.conf files (overrides).

>>3) reads up /etc/bluetooth/$dev.conf (if any)
>>
>>4) starts the stack
>>
>>even though /etc/bluetooth/{default,$dev}.conf are not exactly shell
>>scripts they are still kinda like shell scripts :) these files should
>>follow sh(1) syntax to set the variable, comments etc.
>>
>>the parser in bluetooth_read_conf() is very simple and value of a
>>variable is still used in sh(1) eval. so one must be careful when
>>editing these files.
>>
>>is this looks like something? i also could write
>>bluetooth.device.conf(5) man page that describes the parameters as well
>>as the syntax of the files.
>
> A bluetooth.device.conf(5) man page would be a good idea, though the
> example file is quite good.

agreed.

thanks,
max
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] rc.d integration for the bluetooth subsystem

Yar Tikhiy-2
In reply to this post by Maksim Yevmenkin
On Mon, Nov 07, 2005 at 10:27:23AM -0800, Maksim Yevmenkin wrote:
> Yar Tikhiy wrote:
>
> if expr "$_line" : "[a-zA-Z0-9_]*=" > /dev/null 2>&1 ; then
> ...
> fi
>
> i do not really have any objection to this. since i already pass the
> value through eval i might as well pass the entire line.

And so the users will be able to use basic sh(1) tricks in the lines.

> >And AFAIK stdin to a while loop can be redirected w/o enclosing
> >the loop in braces.
>
> sure, but it looked more clear (to me anyway) this way :)

Hmmm, I'm unsure if it worked at all ;-)  In sh(1) you need to
place a ';' before '}' if there is no '\n' after the last command
in braces.  That is, the sh(1) syntax dictates that you can write

        { command1; command2; }

or
        {
                command1
                command2
        }

but not

        { command1
          command2 }

In the last case '}' will be passed as an argument to command2
and shell will croak on brace mismatch.

For some reason '}' behaves like a command itself in sh(1),
unlike ')'.

--
Yar
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] rc.d integration for the bluetooth subsystem

Maksim Yevmenkin
Yar,

>>if expr "$_line" : "[a-zA-Z0-9_]*=" > /dev/null 2>&1 ; then
>>...
>>fi
>>
>>i do not really have any objection to this. since i already pass the
>>value through eval i might as well pass the entire line.
>
> And so the users will be able to use basic sh(1) tricks in the lines.

depending on one's position it may or may not be a good thing :)

>>>And AFAIK stdin to a while loop can be redirected w/o enclosing
>>>the loop in braces.
>>
>>sure, but it looked more clear (to me anyway) this way :)
>
> Hmmm, I'm unsure if it worked at all ;-)  In sh(1) you need to
> place a ';' before '}' if there is no '\n' after the last command
> in braces.  That is, the sh(1) syntax dictates that you can write

it works. i tried these patches on my system. also there is a similar
code in /etc/rc.subr (please see devfs_rulesets_from_file() function).
but if it make sh(1) purists uncomfortable i certainly can change it :)

thanks,
max
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] rc.d integration for the bluetooth subsystem

Brooks Davis
In reply to this post by Maksim Yevmenkin
On Tue, Nov 08, 2005 at 10:13:08AM -0800, Maksim Yevmenkin wrote:

> Brooks,
>
> >>please find next revision of bluetooth-rc stuff at
> >>
> >>http://people.freebsd.org/~emax/bluetooth-rc-1.diff.txt
> >>
> >>in this revision i have moved all bluetooth configuration files under
> >>/etc/bluetooth. bluetooth.device.sample is now called 'default.conf' and
> >>file that contain device specific overrides called '$dev.conf' (i.e.
> >>'ubt0.conf').
> >>
> >>so, '/etc/rc.d/bluetooth start $dev' does the following
> >>
> >>1) sets hardwired defaults (for backward compatibility)
> >>
> >>2) reads up /etc/bluetooth/default.conf (if any)
> >
> >I think /etc/defaults/bluetooth.device.conf might be better since we do
> >have a defined location of default files and this will discourge people
> >from messing with them.
>
> that is fine with me. i'm sorry this is taking so long :) now the last
> question: should we keep device specific files under /etc/bluetooth or
> just under /etc? right now i have devfs.rules, pccard.conf,
> periodic.conf and rc.conf under /etc/defaults. overrides for these go
> into /etc.
>
> another alternative (which probably no one is going to like) is to use
> /etc/bluetooth/defaults/device.conf (defaults) and
> /etc/bluetooth/$dev.conf files (overrides).

I think they should go in /etc/bluetooth/$dev.conf and the defults
should go in /etc/defaults.  The per-device files should not go directly
in /etc because there is more that one of them.

-- Brooks
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "[hidden email]"
12