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>
 <3DAED89D-72AC-4D38-A092-D2A52AEEE5BB@holtmann.org>
In-Reply-To: <3DAED89D-72AC-4D38-A092-D2A52AEEE5BB@holtmann.org>
From:   Sonny Sasaka <sonnysasaka@chromium.org>
Date:   Thu, 10 Mar 2022 10:30:56 -0800
Message-ID: <CAO271mmX+jMbcuskH23FnWBZc2Or05wLuAc9n6B1Or4g145OTA@mail.gmail.com>
Subject: Re: [RFC] Bluetooth: Adding support for /etc/bluetooth/main.conf.d
To:     Marcel Holtmann <marcel@holtmann.org>
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 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=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
>
> actually I rather not do this. Let met try to explain this. In modern dis=
tribution 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/ actua=
lly. 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.c=
onf then it is doing something wrong (mind you we don=E2=80=99t install it =
by default).
>
> That said, some time ago I discussed with Alain, that fundamentally you f=
irst need an option to identify your controller, what firmware etc. and the=
n 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 pa=
rameters to add known good parameters / workaround to broken hardware.
>
> If you say, that you already know all of this anyway upfront and your fil=
esystem is specific for a given platform, then use tmpfs for /etc/bluetooth=
/main.conf or alternatively, we actually introduce support for CONFIGURATIO=
N_DIRECTORY. We already have this in iwd and it would make sense to just su=
pport it.
>
> The CONFIGURATION_DIRECTORY directory comes from systemd (https://www.fre=
edesktop.org/software/systemd/man/systemd.exec.html), but since it is just =
an environment variable for the bluetoothd process, you can do with any she=
ll 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
>