[RFC] Bluetooth: Adding support for /etc/bluetooth/main.conf.d

[RFC] Bluetooth: Adding support for /etc/bluetooth/main.conf.d

[Katherine Lai]

Background

It was found that a change to the default settings for
MinConnectionInterval and MaxConnectionInterval in main.conf broke
some of ChromeOS’s keyboard HID tests for only certain Bluetooth
controllers. These keyboards aren’t able to connect to the device.
Since those connection parameters improve the connection interval for
most other chipsets, we want to leave the default values but have a
way to have an optional override to address problematic models.


Proposed Solution

Adding support to bluetoothd for an additional config directory
/etc/bluetooth/main.conf.d containing multiple files which will
override common params. Override order will be lexically sorted
filename order. This pattern is already used by Linux distros, for
example there is /etc/sudoers.d which files will override common
params in /etc/sudoers.

Users can add override config files to /etc/bluetooth/main.conf.d
rather than directly editing /etc/bluetooth/main.conf. This is more
friendly to package managers since BlueZ package updates won't cause
conflict to /etc/bluetooth/main.conf.

In bluez’s main.c, merge the params for each *.conf file from
/etc/bluetooth/main.conf.d with the existing /etc/bluetooth/main.conf
in lexical filename order

/etc/bluetooth/main.conf.d will be configurable at build time, e.g.
with ./configure --main-conf-dir

Re: [RFC] Bluetooth: Adding support for /etc/bluetooth/main.conf.d

[Bastien Nocera]

Hey Katherine,

On Mon, 2022-03-07 at 10:57 -0800, Katherine Lai wrote:
> Background
> 
> It was found that a change to the default settings for
> MinConnectionInterval and MaxConnectionInterval in main.conf broke
> some of ChromeOS’s keyboard HID tests for only certain Bluetooth
> controllers. These keyboards aren’t able to connect to the device.
> Since those connection parameters improve the connection interval for
> most other chipsets, we want to leave the default values but have a
> way to have an optional override to address problematic models.
> 
> 
> Proposed Solution
> 
> Adding support to bluetoothd for an additional config directory
> /etc/bluetooth/main.conf.d containing multiple files which will
> override common params. Override order will be lexically sorted
> filename order. This pattern is already used by Linux distros, for
> example there is /etc/sudoers.d which files will override common
> params in /etc/sudoers.
> 
> Users can add override config files to /etc/bluetooth/main.conf.d
> rather than directly editing /etc/bluetooth/main.conf. This is more
> friendly to package managers since BlueZ package updates won't cause
> conflict to /etc/bluetooth/main.conf.
> 
> In bluez’s main.c, merge the params for each *.conf file from
> /etc/bluetooth/main.conf.d with the existing /etc/bluetooth/main.conf
> in lexical filename order
> 
> /etc/bluetooth/main.conf.d will be configurable at build time, e.g.
> with ./configure --main-conf-dir

This isn't quite how the pattern is usually used. With the existing
patterns, the OS-supplied stock configuration would be in
/usr/lib/bluetooth/main.conf.d (maybe with the default .conf in the
same directory as that subdir), with /etc/bluetooth/main.conf.d only
used for the user/admin override the default configuration.

I don't think that making it optional, or have the path changeable is
needed, but the rest seems good.

Cheers

Re: [RFC] Bluetooth: Adding support for /etc/bluetooth/main.conf.d

[Sonny Sasaka]

Hi Bastien,


On Tue, Mar 8, 2022 at 2:14 AM Bastien Nocera <hadess@hadess.net> wrote:
>
> Hey Katherine,
>
> On Mon, 2022-03-07 at 10:57 -0800, Katherine Lai wrote:
> > Background
> >
> > It was found that a change to the default settings for
> > MinConnectionInterval and MaxConnectionInterval in main.conf broke
> > some of ChromeOS’s keyboard HID tests for only certain Bluetooth
> > controllers. These keyboards aren’t able to connect to the device.
> > Since those connection parameters improve the connection interval for
> > most other chipsets, we want to leave the default values but have a
> > way to have an optional override to address problematic models.
> >
> >
> > Proposed Solution
> >
> > Adding support to bluetoothd for an additional config directory
> > /etc/bluetooth/main.conf.d containing multiple files which will
> > override common params. Override order will be lexically sorted
> > filename order. This pattern is already used by Linux distros, for
> > example there is /etc/sudoers.d which files will override common
> > params in /etc/sudoers.
> >
> > Users can add override config files to /etc/bluetooth/main.conf.d
> > rather than directly editing /etc/bluetooth/main.conf. This is more
> > friendly to package managers since BlueZ package updates won't cause
> > conflict to /etc/bluetooth/main.conf.
> >
> > In bluez’s main.c, merge the params for each *.conf file from
> > /etc/bluetooth/main.conf.d with the existing /etc/bluetooth/main.conf
> > in lexical filename order
> >
> > /etc/bluetooth/main.conf.d will be configurable at build time, e.g.
> > with ./configure --main-conf-dir
>
> This isn't quite how the pattern is usually used. With the existing
> patterns, the OS-supplied stock configuration would be in
> /usr/lib/bluetooth/main.conf.d (maybe with the default .conf in the
> same directory as that subdir), with /etc/bluetooth/main.conf.d only
> used for the user/admin override the default configuration.
We did a bit of research and found that /etc/X and /etc/X.d is more
common, e.g. the one described in
https://www.redhat.com/sysadmin/etc-configuration-directories.
If some distribution wants to organize the conf files to
/usr/lib/bluetooth (for stock by package managers) and
/etc/bluetooth/main.conf.d (for admin/users), I guess this is where
having a configurable path is useful.
What do you think?
>
> I don't think that making it optional, or have the path changeable is
> needed, but the rest seems good.
>
> Cheers

Re: [RFC] Bluetooth: Adding support for /etc/bluetooth/main.conf.d

[Bastien Nocera]

On Tue, 2022-03-08 at 14:50 -0800, Sonny Sasaka wrote:
> Hi Bastien,
> 
> 
> On Tue, Mar 8, 2022 at 2:14 AM Bastien Nocera <hadess@hadess.net>
> wrote:
> > 
> > Hey Katherine,
> > 
> > On Mon, 2022-03-07 at 10:57 -0800, Katherine Lai wrote:
> > > Background
> > > 
> > > It was found that a change to the default settings for
> > > MinConnectionInterval and MaxConnectionInterval in main.conf
> > > broke
> > > some of ChromeOS’s keyboard HID tests for only certain Bluetooth
> > > controllers. These keyboards aren’t able to connect to the
> > > device.
> > > Since those connection parameters improve the connection interval
> > > for
> > > most other chipsets, we want to leave the default values but have
> > > a
> > > way to have an optional override to address problematic models.
> > > 
> > > 
> > > Proposed Solution
> > > 
> > > Adding support to bluetoothd for an additional config directory
> > > /etc/bluetooth/main.conf.d containing multiple files which will
> > > override common params. Override order will be lexically sorted
> > > filename order. This pattern is already used by Linux distros,
> > > for
> > > example there is /etc/sudoers.d which files will override common
> > > params in /etc/sudoers.
> > > 
> > > Users can add override config files to /etc/bluetooth/main.conf.d
> > > rather than directly editing /etc/bluetooth/main.conf. This is
> > > more
> > > friendly to package managers since BlueZ package updates won't
> > > cause
> > > conflict to /etc/bluetooth/main.conf.
> > > 
> > > In bluez’s main.c, merge the params for each *.conf file from
> > > /etc/bluetooth/main.conf.d with the existing
> > > /etc/bluetooth/main.conf
> > > in lexical filename order
> > > 
> > > /etc/bluetooth/main.conf.d will be configurable at build time,
> > > e.g.
> > > with ./configure --main-conf-dir
> > 
> > This isn't quite how the pattern is usually used. With the existing
> > patterns, the OS-supplied stock configuration would be in
> > /usr/lib/bluetooth/main.conf.d (maybe with the default .conf in the
> > same directory as that subdir), with /etc/bluetooth/main.conf.d
> > only
> > used for the user/admin override the default configuration.
> We did a bit of research and found that /etc/X and /etc/X.d is more
> common, e.g. the one described in
> https://www.redhat.com/sysadmin/etc-configuration-directories.

This is documentation for an enterprise distribution, not how the
pattern is now used upstream.

$ ls -d1 /usr/lib/*.d/
/usr/lib/binfmt.d/
/usr/lib/environment.d/
/usr/lib/modprobe.d/
/usr/lib/modules-load.d/
/usr/lib/motd.d/
/usr/lib/pam.d/
/usr/lib/sysctl.d/
/usr/lib/sysusers.d/
/usr/lib/tmpfiles.d/
$ ls -d1 /usr/lib/*/*.d/
/usr/lib/dracut/dracut.conf.d/
/usr/lib/dracut/modules.d/
/usr/lib/fedora-third-party/conf.d/
/usr/lib/gconv/gconv-modules.d/
/usr/lib/kernel/install.d/
/usr/lib/NetworkManager/conf.d/
/usr/lib/NetworkManager/dispatcher.d/
/usr/lib/rpm/macros.d/
/usr/lib/systemd/ntp-units.d/
/usr/lib/udev/hwdb.d/
/usr/lib/udev/rules.d/

> If some distribution wants to organize the conf files to
> /usr/lib/bluetooth (for stock by package managers) and
> /etc/bluetooth/main.conf.d (for admin/users), I guess this is where
> having a configurable path is useful.
> What do you think?

I'm saying this isn't the current pattern, especially for OSes where
/usr is locked-down. I still think this isn't the right way to
implement this feature.

Re: [RFC] Bluetooth: Adding support for /etc/bluetooth/main.conf.d

[Sonny Sasaka]

Hi Bastien,

On Wed, Mar 9, 2022 at 1:17 AM Bastien Nocera <hadess@hadess.net> wrote:
>
> On Tue, 2022-03-08 at 14:50 -0800, Sonny Sasaka wrote:
> > Hi Bastien,
> >
> >
> > On Tue, Mar 8, 2022 at 2:14 AM Bastien Nocera <hadess@hadess.net>
> > wrote:
> > >
> > > Hey Katherine,
> > >
> > > On Mon, 2022-03-07 at 10:57 -0800, Katherine Lai wrote:
> > > > Background
> > > >
> > > > It was found that a change to the default settings for
> > > > MinConnectionInterval and MaxConnectionInterval in main.conf
> > > > broke
> > > > some of ChromeOS’s keyboard HID tests for only certain Bluetooth
> > > > controllers. These keyboards aren’t able to connect to the
> > > > device.
> > > > Since those connection parameters improve the connection interval
> > > > for
> > > > most other chipsets, we want to leave the default values but have
> > > > a
> > > > way to have an optional override to address problematic models.
> > > >
> > > >
> > > > Proposed Solution
> > > >
> > > > Adding support to bluetoothd for an additional config directory
> > > > /etc/bluetooth/main.conf.d containing multiple files which will
> > > > override common params. Override order will be lexically sorted
> > > > filename order. This pattern is already used by Linux distros,
> > > > for
> > > > example there is /etc/sudoers.d which files will override common
> > > > params in /etc/sudoers.
> > > >
> > > > Users can add override config files to /etc/bluetooth/main.conf.d
> > > > rather than directly editing /etc/bluetooth/main.conf. This is
> > > > more
> > > > friendly to package managers since BlueZ package updates won't
> > > > cause
> > > > conflict to /etc/bluetooth/main.conf.
> > > >
> > > > In bluez’s main.c, merge the params for each *.conf file from
> > > > /etc/bluetooth/main.conf.d with the existing
> > > > /etc/bluetooth/main.conf
> > > > in lexical filename order
> > > >
> > > > /etc/bluetooth/main.conf.d will be configurable at build time,
> > > > e.g.
> > > > with ./configure --main-conf-dir
> > >
> > > This isn't quite how the pattern is usually used. With the existing
> > > patterns, the OS-supplied stock configuration would be in
> > > /usr/lib/bluetooth/main.conf.d (maybe with the default .conf in the
> > > same directory as that subdir), with /etc/bluetooth/main.conf.d
> > > only
> > > used for the user/admin override the default configuration.
> > We did a bit of research and found that /etc/X and /etc/X.d is more
> > common, e.g. the one described in
> > https://www.redhat.com/sysadmin/etc-configuration-directories.
>
> This is documentation for an enterprise distribution, not how the
> pattern is now used upstream.
>
> $ ls -d1 /usr/lib/*.d/
> /usr/lib/binfmt.d/
> /usr/lib/environment.d/
> /usr/lib/modprobe.d/
> /usr/lib/modules-load.d/
> /usr/lib/motd.d/
> /usr/lib/pam.d/
> /usr/lib/sysctl.d/
> /usr/lib/sysusers.d/
> /usr/lib/tmpfiles.d/
> $ ls -d1 /usr/lib/*/*.d/
> /usr/lib/dracut/dracut.conf.d/
> /usr/lib/dracut/modules.d/
> /usr/lib/fedora-third-party/conf.d/
> /usr/lib/gconv/gconv-modules.d/
> /usr/lib/kernel/install.d/
> /usr/lib/NetworkManager/conf.d/
> /usr/lib/NetworkManager/dispatcher.d/
> /usr/lib/rpm/macros.d/
> /usr/lib/systemd/ntp-units.d/
> /usr/lib/udev/hwdb.d/
> /usr/lib/udev/rules.d/
The proposal doesn't actually define the location of the .d directory,
the proposal only states that bluetoothd will have the capability to
have a .d directory defined at compile time and used at runtime.
As I mentioned earlier, this is where configurability at build time
will be useful.
For example, for the enterprise distribution that you just mentioned,
BlueZ can be configured to have the stock conf at
/usr/lib/bluetooth/main.conf (locked down), and user/admin overrides
at /etc/bluetooth/main.conf.d.
If I understand your concern correctly, this should solve the problem
with this different configuration file layout. If I misunderstand
something let me know.
>
> > If some distribution wants to organize the conf files to
> > /usr/lib/bluetooth (for stock by package managers) and
> > /etc/bluetooth/main.conf.d (for admin/users), I guess this is where
> > having a configurable path is useful.
> > What do you think?
>
> I'm saying this isn't the current pattern, especially for OSes where
> /usr is locked-down. I still think this isn't the right way to
> implement this feature.
Could you elaborate why providing a .d overrides directory isn't
right? I can mention an example use case: BlueZ ships at a distro with
certain values of MinConnectionInterval and MaxConnectionInterval in
the stock configuration. The user realizes that these values don't
work well with the Bluetooth controller hardware, maybe LE keyboards
don't reconnect well. They then want to configure this values, but
don't want to edit the stock conf because maybe it's locked or they
don't want to mess with files provided with the package manager. The
user can then use the override directory to customize the values for
MinConnectionInterval and MaxConnectionInterval to make the keyboard
work.

I think that the proposal solves the use case above. If you think this
is not the right approach, could you elaborate why and suggest an
alternative we can consider?

Re: [RFC] Bluetooth: Adding support for /etc/bluetooth/main.conf.d

[Luiz Augusto von Dentz]

Hi,

On Wed, Mar 9, 2022 at 4:10 AM Bastien Nocera <hadess@hadess.net> wrote:
>
> On Tue, 2022-03-08 at 14:50 -0800, Sonny Sasaka wrote:
> > Hi Bastien,
> >
> >
> > On Tue, Mar 8, 2022 at 2:14 AM Bastien Nocera <hadess@hadess.net>
> > wrote:
> > >
> > > Hey Katherine,
> > >
> > > On Mon, 2022-03-07 at 10:57 -0800, Katherine Lai wrote:
> > > > Background
> > > >
> > > > It was found that a change to the default settings for
> > > > MinConnectionInterval and MaxConnectionInterval in main.conf
> > > > broke
> > > > some of ChromeOS’s keyboard HID tests for only certain Bluetooth
> > > > controllers. These keyboards aren’t able to connect to the
> > > > device.
> > > > Since those connection parameters improve the connection interval
> > > > for
> > > > most other chipsets, we want to leave the default values but have
> > > > a
> > > > way to have an optional override to address problematic models.
> > > >
> > > >
> > > > Proposed Solution
> > > >
> > > > Adding support to bluetoothd for an additional config directory
> > > > /etc/bluetooth/main.conf.d containing multiple files which will
> > > > override common params. Override order will be lexically sorted
> > > > filename order. This pattern is already used by Linux distros,
> > > > for
> > > > example there is /etc/sudoers.d which files will override common
> > > > params in /etc/sudoers.
> > > >
> > > > Users can add override config files to /etc/bluetooth/main.conf.d
> > > > rather than directly editing /etc/bluetooth/main.conf. This is
> > > > more
> > > > friendly to package managers since BlueZ package updates won't
> > > > cause
> > > > conflict to /etc/bluetooth/main.conf.
> > > >
> > > > In bluez’s main.c, merge the params for each *.conf file from
> > > > /etc/bluetooth/main.conf.d with the existing
> > > > /etc/bluetooth/main.conf
> > > > in lexical filename order
> > > >
> > > > /etc/bluetooth/main.conf.d will be configurable at build time,
> > > > e.g.
> > > > with ./configure --main-conf-dir
> > >
> > > This isn't quite how the pattern is usually used. With the existing
> > > patterns, the OS-supplied stock configuration would be in
> > > /usr/lib/bluetooth/main.conf.d (maybe with the default .conf in the
> > > same directory as that subdir), with /etc/bluetooth/main.conf.d
> > > only
> > > used for the user/admin override the default configuration.
> > We did a bit of research and found that /etc/X and /etc/X.d is more
> > common, e.g. the one described in
> > https://www.redhat.com/sysadmin/etc-configuration-directories.
>
> This is documentation for an enterprise distribution, not how the
> pattern is now used upstream.
>
> $ ls -d1 /usr/lib/*.d/
> /usr/lib/binfmt.d/
> /usr/lib/environment.d/
> /usr/lib/modprobe.d/
> /usr/lib/modules-load.d/
> /usr/lib/motd.d/
> /usr/lib/pam.d/
> /usr/lib/sysctl.d/
> /usr/lib/sysusers.d/
> /usr/lib/tmpfiles.d/
> $ ls -d1 /usr/lib/*/*.d/
> /usr/lib/dracut/dracut.conf.d/
> /usr/lib/dracut/modules.d/
> /usr/lib/fedora-third-party/conf.d/
> /usr/lib/gconv/gconv-modules.d/
> /usr/lib/kernel/install.d/
> /usr/lib/NetworkManager/conf.d/
> /usr/lib/NetworkManager/dispatcher.d/
> /usr/lib/rpm/macros.d/
> /usr/lib/systemd/ntp-units.d/
> /usr/lib/udev/hwdb.d/
> /usr/lib/udev/rules.d/
>
> > If some distribution wants to organize the conf files to
> > /usr/lib/bluetooth (for stock by package managers) and
> > /etc/bluetooth/main.conf.d (for admin/users), I guess this is where
> > having a configurable path is useful.
> > What do you think?
>
> I'm saying this isn't the current pattern, especially for OSes where
> /usr is locked-down. I still think this isn't the right way to
> implement this feature.

Before we start doing this we should check if the devices with
problems don't implement Peripheral Preferred Connection Parameters
(PPCP) as some of peripherals are not capable of updating the
connection parameters themselves they depend on the central reading
the PPCP, some years back we got someone attempting to implement PPCP
support but the problem was that one needs to load all the devices
connection parameters with Peripheral Preferred Connection Parameters
management command, anyway it would be great to have support for PPCP
even if that means reloading everything or perhaps we introduce
something at socket level where the user can set the parameters which
then gets saved once the update connection parameters procedure is
completed.

-- 
Luiz Augusto von Dentz

Re: [RFC] Bluetooth: Adding support for /etc/bluetooth/main.conf.d

[Luiz Augusto von Dentz]

Hi,

On Wed, Mar 9, 2022 at 12:44 PM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
>
> Hi,
>
> On Wed, Mar 9, 2022 at 4:10 AM Bastien Nocera <hadess@hadess.net> wrote:
> >
> > On Tue, 2022-03-08 at 14:50 -0800, Sonny Sasaka wrote:
> > > Hi Bastien,
> > >
> > >
> > > On Tue, Mar 8, 2022 at 2:14 AM Bastien Nocera <hadess@hadess.net>
> > > wrote:
> > > >
> > > > Hey Katherine,
> > > >
> > > > On Mon, 2022-03-07 at 10:57 -0800, Katherine Lai wrote:
> > > > > Background
> > > > >
> > > > > It was found that a change to the default settings for
> > > > > MinConnectionInterval and MaxConnectionInterval in main.conf
> > > > > broke
> > > > > some of ChromeOS’s keyboard HID tests for only certain Bluetooth
> > > > > controllers. These keyboards aren’t able to connect to the
> > > > > device.
> > > > > Since those connection parameters improve the connection interval
> > > > > for
> > > > > most other chipsets, we want to leave the default values but have
> > > > > a
> > > > > way to have an optional override to address problematic models.
> > > > >
> > > > >
> > > > > Proposed Solution
> > > > >
> > > > > Adding support to bluetoothd for an additional config directory
> > > > > /etc/bluetooth/main.conf.d containing multiple files which will
> > > > > override common params. Override order will be lexically sorted
> > > > > filename order. This pattern is already used by Linux distros,
> > > > > for
> > > > > example there is /etc/sudoers.d which files will override common
> > > > > params in /etc/sudoers.
> > > > >
> > > > > Users can add override config files to /etc/bluetooth/main.conf.d
> > > > > rather than directly editing /etc/bluetooth/main.conf. This is
> > > > > more
> > > > > friendly to package managers since BlueZ package updates won't
> > > > > cause
> > > > > conflict to /etc/bluetooth/main.conf.
> > > > >
> > > > > In bluez’s main.c, merge the params for each *.conf file from
> > > > > /etc/bluetooth/main.conf.d with the existing
> > > > > /etc/bluetooth/main.conf
> > > > > in lexical filename order
> > > > >
> > > > > /etc/bluetooth/main.conf.d will be configurable at build time,
> > > > > e.g.
> > > > > with ./configure --main-conf-dir
> > > >
> > > > This isn't quite how the pattern is usually used. With the existing
> > > > patterns, the OS-supplied stock configuration would be in
> > > > /usr/lib/bluetooth/main.conf.d (maybe with the default .conf in the
> > > > same directory as that subdir), with /etc/bluetooth/main.conf.d
> > > > only
> > > > used for the user/admin override the default configuration.
> > > We did a bit of research and found that /etc/X and /etc/X.d is more
> > > common, e.g. the one described in
> > > https://www.redhat.com/sysadmin/etc-configuration-directories.
> >
> > This is documentation for an enterprise distribution, not how the
> > pattern is now used upstream.
> >
> > $ ls -d1 /usr/lib/*.d/
> > /usr/lib/binfmt.d/
> > /usr/lib/environment.d/
> > /usr/lib/modprobe.d/
> > /usr/lib/modules-load.d/
> > /usr/lib/motd.d/
> > /usr/lib/pam.d/
> > /usr/lib/sysctl.d/
> > /usr/lib/sysusers.d/
> > /usr/lib/tmpfiles.d/
> > $ ls -d1 /usr/lib/*/*.d/
> > /usr/lib/dracut/dracut.conf.d/
> > /usr/lib/dracut/modules.d/
> > /usr/lib/fedora-third-party/conf.d/
> > /usr/lib/gconv/gconv-modules.d/
> > /usr/lib/kernel/install.d/
> > /usr/lib/NetworkManager/conf.d/
> > /usr/lib/NetworkManager/dispatcher.d/
> > /usr/lib/rpm/macros.d/
> > /usr/lib/systemd/ntp-units.d/
> > /usr/lib/udev/hwdb.d/
> > /usr/lib/udev/rules.d/
> >
> > > If some distribution wants to organize the conf files to
> > > /usr/lib/bluetooth (for stock by package managers) and
> > > /etc/bluetooth/main.conf.d (for admin/users), I guess this is where
> > > having a configurable path is useful.
> > > What do you think?
> >
> > I'm saying this isn't the current pattern, especially for OSes where
> > /usr is locked-down. I still think this isn't the right way to
> > implement this feature.
>
> Before we start doing this we should check if the devices with
> problems don't implement Peripheral Preferred Connection Parameters
> (PPCP) as some of peripherals are not capable of updating the
> connection parameters themselves they depend on the central reading
> the PPCP, some years back we got someone attempting to implement PPCP
> support but the problem was that one needs to load all the devices
> connection parameters with Peripheral Preferred Connection Parameters
> management command, anyway it would be great to have support for PPCP
> even if that means reloading everything or perhaps we introduce
> something at socket level where the user can set the parameters which
> then gets saved once the update connection parameters procedure is
> completed.

Here it is the RFC for the kernel side:

https://www.spinics.net/lists/linux-bluetooth/msg69520.html

It probably needs some improvements like checkinf if the conneciton is
really LE, etc.

> --
> Luiz Augusto von Dentz



-- 
Luiz Augusto von Dentz

Re: [RFC] Bluetooth: Adding support for /etc/bluetooth/main.conf.d

[Sonny Sasaka]

Hi Luiz,

On Wed, Mar 9, 2022 at 1:02 PM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
>
> Hi,
>
> On Wed, Mar 9, 2022 at 12:44 PM Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
> >
> > Hi,
> >
> > On Wed, Mar 9, 2022 at 4:10 AM Bastien Nocera <hadess@hadess.net> wrote:
> > >
> > > On Tue, 2022-03-08 at 14:50 -0800, Sonny Sasaka wrote:
> > > > Hi Bastien,
> > > >
> > > >
> > > > On Tue, Mar 8, 2022 at 2:14 AM Bastien Nocera <hadess@hadess.net>
> > > > wrote:
> > > > >
> > > > > Hey Katherine,
> > > > >
> > > > > On Mon, 2022-03-07 at 10:57 -0800, Katherine Lai wrote:
> > > > > > Background
> > > > > >
> > > > > > It was found that a change to the default settings for
> > > > > > MinConnectionInterval and MaxConnectionInterval in main.conf
> > > > > > broke
> > > > > > some of ChromeOS’s keyboard HID tests for only certain Bluetooth
> > > > > > controllers. These keyboards aren’t able to connect to the
> > > > > > device.
> > > > > > Since those connection parameters improve the connection interval
> > > > > > for
> > > > > > most other chipsets, we want to leave the default values but have
> > > > > > a
> > > > > > way to have an optional override to address problematic models.
> > > > > >
> > > > > >
> > > > > > Proposed Solution
> > > > > >
> > > > > > Adding support to bluetoothd for an additional config directory
> > > > > > /etc/bluetooth/main.conf.d containing multiple files which will
> > > > > > override common params. Override order will be lexically sorted
> > > > > > filename order. This pattern is already used by Linux distros,
> > > > > > for
> > > > > > example there is /etc/sudoers.d which files will override common
> > > > > > params in /etc/sudoers.
> > > > > >
> > > > > > Users can add override config files to /etc/bluetooth/main.conf.d
> > > > > > rather than directly editing /etc/bluetooth/main.conf. This is
> > > > > > more
> > > > > > friendly to package managers since BlueZ package updates won't
> > > > > > cause
> > > > > > conflict to /etc/bluetooth/main.conf.
> > > > > >
> > > > > > In bluez’s main.c, merge the params for each *.conf file from
> > > > > > /etc/bluetooth/main.conf.d with the existing
> > > > > > /etc/bluetooth/main.conf
> > > > > > in lexical filename order
> > > > > >
> > > > > > /etc/bluetooth/main.conf.d will be configurable at build time,
> > > > > > e.g.
> > > > > > with ./configure --main-conf-dir
> > > > >
> > > > > This isn't quite how the pattern is usually used. With the existing
> > > > > patterns, the OS-supplied stock configuration would be in
> > > > > /usr/lib/bluetooth/main.conf.d (maybe with the default .conf in the
> > > > > same directory as that subdir), with /etc/bluetooth/main.conf.d
> > > > > only
> > > > > used for the user/admin override the default configuration.
> > > > We did a bit of research and found that /etc/X and /etc/X.d is more
> > > > common, e.g. the one described in
> > > > https://www.redhat.com/sysadmin/etc-configuration-directories.
> > >
> > > This is documentation for an enterprise distribution, not how the
> > > pattern is now used upstream.
> > >
> > > $ ls -d1 /usr/lib/*.d/
> > > /usr/lib/binfmt.d/
> > > /usr/lib/environment.d/
> > > /usr/lib/modprobe.d/
> > > /usr/lib/modules-load.d/
> > > /usr/lib/motd.d/
> > > /usr/lib/pam.d/
> > > /usr/lib/sysctl.d/
> > > /usr/lib/sysusers.d/
> > > /usr/lib/tmpfiles.d/
> > > $ ls -d1 /usr/lib/*/*.d/
> > > /usr/lib/dracut/dracut.conf.d/
> > > /usr/lib/dracut/modules.d/
> > > /usr/lib/fedora-third-party/conf.d/
> > > /usr/lib/gconv/gconv-modules.d/
> > > /usr/lib/kernel/install.d/
> > > /usr/lib/NetworkManager/conf.d/
> > > /usr/lib/NetworkManager/dispatcher.d/
> > > /usr/lib/rpm/macros.d/
> > > /usr/lib/systemd/ntp-units.d/
> > > /usr/lib/udev/hwdb.d/
> > > /usr/lib/udev/rules.d/
> > >
> > > > If some distribution wants to organize the conf files to
> > > > /usr/lib/bluetooth (for stock by package managers) and
> > > > /etc/bluetooth/main.conf.d (for admin/users), I guess this is where
> > > > having a configurable path is useful.
> > > > What do you think?
> > >
> > > I'm saying this isn't the current pattern, especially for OSes where
> > > /usr is locked-down. I still think this isn't the right way to
> > > implement this feature.
> >
> > Before we start doing this we should check if the devices with
> > problems don't implement Peripheral Preferred Connection Parameters
> > (PPCP) as some of peripherals are not capable of updating the
> > connection parameters themselves they depend on the central reading
> > the PPCP, some years back we got someone attempting to implement PPCP
> > support but the problem was that one needs to load all the devices
> > connection parameters with Peripheral Preferred Connection Parameters
> > management command, anyway it would be great to have support for PPCP
> > even if that means reloading everything or perhaps we introduce
> > something at socket level where the user can set the parameters which
> > then gets saved once the update connection parameters procedure is
> > completed.
In our case, the problem is not with the peripherals but with a
specific Bluetooth controller of the central. We can't assume that all
Bluetooth controllers behave well with a certain configuration,
therefore I think that trying to get a one-size-fits-all configuration
will likely run into a problem eventually.

Also, although it's motivated by a specific issue, the solution that
we are proposing is actually a generally helpful feature since there
are other parameters that users may override without modifying the
original configuration that comes from package manager especially when
it is locked down. As a generic override mechanism, what do you think
about this proposal?
>
> Here it is the RFC for the kernel side:
>
> https://www.spinics.net/lists/linux-bluetooth/msg69520.html
>
> It probably needs some improvements like checkinf if the conneciton is
> really LE, etc.
>
> > --
> > Luiz Augusto von Dentz
>
>
>
> --
> Luiz Augusto von Dentz

Re: [RFC] Bluetooth: Adding support for /etc/bluetooth/main.conf.d

[Marcel Holtmann]

Hi Katherine,

> It was found that a change to the default settings for
> MinConnectionInterval and MaxConnectionInterval in main.conf broke
> some of ChromeOS’s keyboard HID tests for only certain Bluetooth
> controllers. These keyboards aren’t able to connect to the device.
> Since those connection parameters improve the connection interval for
> most other chipsets, we want to leave the default values but have a
> way to have an optional override to address problematic models.
> 
> 
> Proposed Solution
> 
> Adding support to bluetoothd for an additional config directory
> /etc/bluetooth/main.conf.d containing multiple files which will
> override common params. Override order will be lexically sorted
> filename order. This pattern is already used by Linux distros, for
> example there is /etc/sudoers.d which files will override common
> params in /etc/sudoers.
> 
> Users can add override config files to /etc/bluetooth/main.conf.d
> rather than directly editing /etc/bluetooth/main.conf. This is more
> friendly to package managers since BlueZ package updates won't cause
> conflict to /etc/bluetooth/main.conf.
> 
> In bluez’s main.c, merge the params for each *.conf file from
> /etc/bluetooth/main.conf.d with the existing /etc/bluetooth/main.conf
> in lexical filename order
> 
> /etc/bluetooth/main.conf.d will be configurable at build time, e.g.
> with ./configure --main-conf-dir

actually I rather not do this. Let met try to explain this. In modern distribution layout, the /etc directory is purely for the admin of the system. They can do localized changes. Defaults are meant to be in /usr/lib/ actually. And override is also meant that an /etc file can fully replace an /usr/lib file.

We already structured that /etc/bluetooth/main.conf is optional and that package managers / distros should only install it if they really know what they are doing. If an upgrade of a package overwrites /etc/bluetooth/main.conf then it is doing something wrong (mind you we don’t install it by default).

That said, some time ago I discussed with Alain, that fundamentally you first need an option to identify your controller, what firmware etc. and then can decide what to load. That thread ended and got no further discussion. Based on that identification we wanted to allow tweaking certain set of parameters to add known good parameters / workaround to broken hardware.

If you say, that you already know all of this anyway upfront and your filesystem is specific for a given platform, then use tmpfs for /etc/bluetooth/main.conf or alternatively, we actually introduce support for CONFIGURATION_DIRECTORY. We already have this in iwd and it would make sense to just support it.

The CONFIGURATION_DIRECTORY directory comes from systemd (https://www.freedesktop.org/software/systemd/man/systemd.exec.html), but since it is just an environment variable for the bluetoothd process, you can do with any shell by just setting it.

Regards

Marcel

Re: [RFC] Bluetooth: Adding support for /etc/bluetooth/main.conf.d

[Sonny Sasaka]

Hi Marcel,

On Thu, Mar 10, 2022 at 1:51 AM Marcel Holtmann <marcel@holtmann.org> wrote:
>
> Hi Katherine,
>
> > It was found that a change to the default settings for
> > MinConnectionInterval and MaxConnectionInterval in main.conf broke
> > some of ChromeOS’s keyboard HID tests for only certain Bluetooth
> > controllers. These keyboards aren’t able to connect to the device.
> > Since those connection parameters improve the connection interval for
> > most other chipsets, we want to leave the default values but have a
> > way to have an optional override to address problematic models.
> >
> >
> > Proposed Solution
> >
> > Adding support to bluetoothd for an additional config directory
> > /etc/bluetooth/main.conf.d containing multiple files which will
> > override common params. Override order will be lexically sorted
> > filename order. This pattern is already used by Linux distros, for
> > example there is /etc/sudoers.d which files will override common
> > params in /etc/sudoers.
> >
> > Users can add override config files to /etc/bluetooth/main.conf.d
> > rather than directly editing /etc/bluetooth/main.conf. This is more
> > friendly to package managers since BlueZ package updates won't cause
> > conflict to /etc/bluetooth/main.conf.
> >
> > In bluez’s main.c, merge the params for each *.conf file from
> > /etc/bluetooth/main.conf.d with the existing /etc/bluetooth/main.conf
> > in lexical filename order
> >
> > /etc/bluetooth/main.conf.d will be configurable at build time, e.g.
> > with ./configure --main-conf-dir
>
> actually I rather not do this. Let met try to explain this. In modern distribution layout, the /etc directory is purely for the admin of the system. They can do localized changes. Defaults are meant to be in /usr/lib/ actually. And override is also meant that an /etc file can fully replace an /usr/lib file.
>
> We already structured that /etc/bluetooth/main.conf is optional and that package managers / distros should only install it if they really know what they are doing. If an upgrade of a package overwrites /etc/bluetooth/main.conf then it is doing something wrong (mind you we don’t install it by default).
>
> That said, some time ago I discussed with Alain, that fundamentally you first need an option to identify your controller, what firmware etc. and then can decide what to load. That thread ended and got no further discussion. Based on that identification we wanted to allow tweaking certain set of parameters to add known good parameters / workaround to broken hardware.
>
> If you say, that you already know all of this anyway upfront and your filesystem is specific for a given platform, then use tmpfs for /etc/bluetooth/main.conf or alternatively, we actually introduce support for CONFIGURATION_DIRECTORY. We already have this in iwd and it would make sense to just support it.
>
> The CONFIGURATION_DIRECTORY directory comes from systemd (https://www.freedesktop.org/software/systemd/man/systemd.exec.html), but since it is just an environment variable for the bluetoothd process, you can do with any shell by just setting it.

If I interpret this correctly, the reason against this proposal isn't
really about the location of the conf (/usr vs /etc), but rather that
BlueZ intends to use the main.conf already as an override (so there is
no need for another override), is that right?

>
> Regards
>
> Marcel
>

Re: [RFC] Bluetooth: Adding support for /etc/bluetooth/main.conf.d

[Marcel Holtmann]

Hi Sonny,

>>> It was found that a change to the default settings for
>>> MinConnectionInterval and MaxConnectionInterval in main.conf broke
>>> some of ChromeOS’s keyboard HID tests for only certain Bluetooth
>>> controllers. These keyboards aren’t able to connect to the device.
>>> Since those connection parameters improve the connection interval for
>>> most other chipsets, we want to leave the default values but have a
>>> way to have an optional override to address problematic models.
>>> 
>>> 
>>> Proposed Solution
>>> 
>>> Adding support to bluetoothd for an additional config directory
>>> /etc/bluetooth/main.conf.d containing multiple files which will
>>> override common params. Override order will be lexically sorted
>>> filename order. This pattern is already used by Linux distros, for
>>> example there is /etc/sudoers.d which files will override common
>>> params in /etc/sudoers.
>>> 
>>> Users can add override config files to /etc/bluetooth/main.conf.d
>>> rather than directly editing /etc/bluetooth/main.conf. This is more
>>> friendly to package managers since BlueZ package updates won't cause
>>> conflict to /etc/bluetooth/main.conf.
>>> 
>>> In bluez’s main.c, merge the params for each *.conf file from
>>> /etc/bluetooth/main.conf.d with the existing /etc/bluetooth/main.conf
>>> in lexical filename order
>>> 
>>> /etc/bluetooth/main.conf.d will be configurable at build time, e.g.
>>> with ./configure --main-conf-dir
>> 
>> actually I rather not do this. Let met try to explain this. In modern distribution layout, the /etc directory is purely for the admin of the system. They can do localized changes. Defaults are meant to be in /usr/lib/ actually. And override is also meant that an /etc file can fully replace an /usr/lib file.
>> 
>> We already structured that /etc/bluetooth/main.conf is optional and that package managers / distros should only install it if they really know what they are doing. If an upgrade of a package overwrites /etc/bluetooth/main.conf then it is doing something wrong (mind you we don’t install it by default).
>> 
>> That said, some time ago I discussed with Alain, that fundamentally you first need an option to identify your controller, what firmware etc. and then can decide what to load. That thread ended and got no further discussion. Based on that identification we wanted to allow tweaking certain set of parameters to add known good parameters / workaround to broken hardware.
>> 
>> If you say, that you already know all of this anyway upfront and your filesystem is specific for a given platform, then use tmpfs for /etc/bluetooth/main.conf or alternatively, we actually introduce support for CONFIGURATION_DIRECTORY. We already have this in iwd and it would make sense to just support it.
>> 
>> The CONFIGURATION_DIRECTORY directory comes from systemd (https://www.freedesktop.org/software/systemd/man/systemd.exec.html), but since it is just an environment variable for the bluetoothd process, you can do with any shell by just setting it.
> 
> If I interpret this correctly, the reason against this proposal isn't
> really about the location of the conf (/usr vs /etc), but rather that
> BlueZ intends to use the main.conf already as an override (so there is
> no need for another override), is that right?

that is one of them. The other is that these days overrides are done differently as mentioned above.

Regards

Marcel

Re: [RFC] Bluetooth: Adding support for /etc/bluetooth/main.conf.d

[Sonny Sasaka]

Thanks for the clarification. We will not be moving forward with this
proposal but will implement overrides in our build system instead.

On Thu, Mar 10, 2022 at 12:04 PM Marcel Holtmann <marcel@holtmann.org> wrote:
>
> Hi Sonny,
>
> >>> It was found that a change to the default settings for
> >>> MinConnectionInterval and MaxConnectionInterval in main.conf broke
> >>> some of ChromeOS’s keyboard HID tests for only certain Bluetooth
> >>> controllers. These keyboards aren’t able to connect to the device.
> >>> Since those connection parameters improve the connection interval for
> >>> most other chipsets, we want to leave the default values but have a
> >>> way to have an optional override to address problematic models.
> >>>
> >>>
> >>> Proposed Solution
> >>>
> >>> Adding support to bluetoothd for an additional config directory
> >>> /etc/bluetooth/main.conf.d containing multiple files which will
> >>> override common params. Override order will be lexically sorted
> >>> filename order. This pattern is already used by Linux distros, for
> >>> example there is /etc/sudoers.d which files will override common
> >>> params in /etc/sudoers.
> >>>
> >>> Users can add override config files to /etc/bluetooth/main.conf.d
> >>> rather than directly editing /etc/bluetooth/main.conf. This is more
> >>> friendly to package managers since BlueZ package updates won't cause
> >>> conflict to /etc/bluetooth/main.conf.
> >>>
> >>> In bluez’s main.c, merge the params for each *.conf file from
> >>> /etc/bluetooth/main.conf.d with the existing /etc/bluetooth/main.conf
> >>> in lexical filename order
> >>>
> >>> /etc/bluetooth/main.conf.d will be configurable at build time, e.g.
> >>> with ./configure --main-conf-dir
> >>
> >> actually I rather not do this. Let met try to explain this. In modern distribution layout, the /etc directory is purely for the admin of the system. They can do localized changes. Defaults are meant to be in /usr/lib/ actually. And override is also meant that an /etc file can fully replace an /usr/lib file.
> >>
> >> We already structured that /etc/bluetooth/main.conf is optional and that package managers / distros should only install it if they really know what they are doing. If an upgrade of a package overwrites /etc/bluetooth/main.conf then it is doing something wrong (mind you we don’t install it by default).
> >>
> >> That said, some time ago I discussed with Alain, that fundamentally you first need an option to identify your controller, what firmware etc. and then can decide what to load. That thread ended and got no further discussion. Based on that identification we wanted to allow tweaking certain set of parameters to add known good parameters / workaround to broken hardware.
> >>
> >> If you say, that you already know all of this anyway upfront and your filesystem is specific for a given platform, then use tmpfs for /etc/bluetooth/main.conf or alternatively, we actually introduce support for CONFIGURATION_DIRECTORY. We already have this in iwd and it would make sense to just support it.
> >>
> >> The CONFIGURATION_DIRECTORY directory comes from systemd (https://www.freedesktop.org/software/systemd/man/systemd.exec.html), but since it is just an environment variable for the bluetoothd process, you can do with any shell by just setting it.
> >
> > If I interpret this correctly, the reason against this proposal isn't
> > really about the location of the conf (/usr vs /etc), but rather that
> > BlueZ intends to use the main.conf already as an override (so there is
> > no need for another override), is that right?
>
> that is one of them. The other is that these days overrides are done differently as mentioned above.
>
> Regards
>
> Marcel
>