Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
MIME-Version: 1.0
References: <CAPBVwTQrcYYauoCXBWdOsPa_vmN=cajYzVFcep_GLC-2OwOwYQ@mail.gmail.com>
 <6f8f47ceebfbcfd7fa8b04a4df807ae822e2960c.camel@hadess.net>
In-Reply-To: <6f8f47ceebfbcfd7fa8b04a4df807ae822e2960c.camel@hadess.net>
From:   Sonny Sasaka <sonnysasaka@chromium.org>
Date:   Tue, 8 Mar 2022 14:50:55 -0800
Message-ID: <CAO271m=hf0uB1t50t6tTXqDQREVxzX2S=R2rVCGK60xwVKgSYQ@mail.gmail.com>
Subject: Re: [RFC] Bluetooth: Adding support for /etc/bluetooth/main.conf.d
To:     Bastien Nocera <hadess@hadess.net>
Cc:     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 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 Bluetoot=
h
> > controllers. These keyboards aren=E2=80=99t able to connect to the devi=
ce.
> > 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=E2=80=99s 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