Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAPBVwTQrcYYauoCXBWdOsPa_vmN=cajYzVFcep_GLC-2OwOwYQ@mail.gmail.com>
 <6f8f47ceebfbcfd7fa8b04a4df807ae822e2960c.camel@hadess.net>
 <CAO271m=hf0uB1t50t6tTXqDQREVxzX2S=R2rVCGK60xwVKgSYQ@mail.gmail.com>
 <f1ab40c531d81135918e0a05cc8b1721b951e958.camel@hadess.net>
 <CABBYNZK9kkA2JQCJ8z-a0asHobxqkSeATtEoPDWxAF=b2TWK5g@mail.gmail.com> <CABBYNZ+rg+=ZOAFdBFhyE=Ki7KL1C=Jq-w2cT3rMTMmoMTt6_w@mail.gmail.com>
In-Reply-To: <CABBYNZ+rg+=ZOAFdBFhyE=Ki7KL1C=Jq-w2cT3rMTMmoMTt6_w@mail.gmail.com>
From:   Sonny Sasaka <sonnysasaka@chromium.org>
Date:   Wed, 9 Mar 2022 15:34:43 -0800
Message-ID: <CAO271mnSPVV0BdmdMLGxREy=4TwHB2ryuxcgpnhiDQJPoEELSA@mail.gmail.com>
Subject: Re: [RFC] Bluetooth: Adding support for /etc/bluetooth/main.conf.d
To:     Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc:     Bastien Nocera <hadess@hadess.net>,
        Katherine Lai <laikatherine@chromium.org>,
        BlueZ <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

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=E2=80=99s keyboard HID tests for only certain =
Bluetooth
> > > > > > controllers. These keyboards aren=E2=80=99t able to connect to =
the
> > > > > > device.
> > > > > > Since those connection parameters improve the connection interv=
al
> > > > > > for
> > > > > > most other chipsets, we want to leave the default values but ha=
ve
> > > > > > 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 commo=
n
> > > > > > 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=E2=80=99s main.c, merge the params for each *.conf fil=
e 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 existi=
ng
> > > > > patterns, the OS-supplied stock configuration would be in
> > > > > /usr/lib/bluetooth/main.conf.d (maybe with the default .conf in t=
he
> > > > > 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