[RFC] rc.d integration for the bluetooth subsystem
Panagiotis Astithas
past at ebs.gr
Wed Oct 19 01:00:47 PDT 2005
Maksim Yevmenkin wrote:
> Panagiotis,
>
> [...]
>
>>>>> In an eventual merge into the base system the devd configuration
>>>>> should be merged into /etc/devd.conf and /etc/defaults/rc.conf
>>>>> should contain the following line instead: bluetooth_enable="NO"
>>>>>
>>>>> I'd appreciate any comments you may have.
>>>
>>>
>>> devd(8) configuration (ubt.conf) looks fine. i can merge this info
>>> devd.conf for you. hcsecd(8) and sdpd(8) already committed into
>>> -current. i have also created bluetooth section in the
>>> /etc/defaults/rc.conf file.
>>>
>>> i have few comments about my original rc.bluetooth script.
>>>
>>> 1) it probably should not load any kernel modules. the problem is
>>> that when one (or more) bluetooth kernel modules compiled into the
>>> kernel the kldstat(8) check may fail. this has to do with the way
>>> kldstat(8) prints the results and the way rc.bluetooth grep's through
>>> them.
>>>
>>> 2) original rc.bluetooth is very rigid. things like device name,
>>> device class, etc. are hardwired into the script. so i'd like to have
>>> a bit of flexibility here, i.e. ability to specify per device
>>>
>>> - device name (change_local_name)
>>>
>>> - device class (write_class_of_device)
>>>
>>> - should device be "visible"/discoverable by default (write_scan_enable)
>>>
>>> - should device request authentication (write_authentication_enable)
>>>
>>> - should device use encryption (write_encryption_enable)
>>>
>>> - should device request role switch (write_node_role_switch)
>>>
>>> and maybe few others.
>>>
>>> 3) i'd like to have some way to execute a few hccontrol(8) commands
>>> after default setup was done. perhaps this could be done with some
>>> sort of bluetooth.local rc.d script that will be executed after main
>>> script. by default it should be empty. another way to do it is to
>>> have something along the bluetooth_extra_commands variable in rc.conf.
>>
>>
>> Thanks for the comments. I understand your concerns and share some of
>> your reservations regarding the rc.bluetooth script (or my rc.d-fied
>> version of it). Nevertheless, I feel that the lack of (some version
>> of) it in the base system, complicates unnecessary the use of the
>> bluetooth stack. I do agree that the goals you describe should be
>> pursued. I would ask you though to consider adding even this
>> imperfect, rigid version in the meantime, while we plan how we can
>> improve on it further. After all devd must execute something, right? :-)
>
>
> that's fine. please give me some time for more careful review. also
> shouldn't rc.bluetooth be in /etc instead of /etc/rc.d? its similar to
> /etc/pccard_ether, is it not?
If you pick rc.bluetooth, yes. On the other hand if you prefer the rc.d
version that I posted, it is more like, say /etc/rc.d/netif, so it
should be in /etc/rc.d. If you are concerned about having a script in
rc.d that is not executed at boot time, there is also the precedent of
/etc/rc.d/dhclient and the other scripts with the nostart keyword.
It is also my impression that rc.foo scripts in /etc are being
deprecated these days, but I might be wrong. We could ask freebsd-rc for
a clarification.
Thanks,
Panagiotis
More information about the freebsd-bluetooth
mailing list