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> <CAO271mmX+jMbcuskH23FnWBZc2Or05wLuAc9n6B1Or4g145OTA@mail.gmail.com>
 <14A05E77-95D3-4313-B9F6-BC654CD96E01@holtmann.org>
In-Reply-To: <14A05E77-95D3-4313-B9F6-BC654CD96E01@holtmann.org>
From:   Sonny Sasaka <sonnysasaka@chromium.org>
Date:   Fri, 18 Mar 2022 13:13:56 -0700
Message-ID: <CAO271m=8i0Pv+ODzvP+gW7YxmGuxAm9232SqBrQ3qhpZfmTYAQ@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

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> wrot=
e:
>
> Hi Sonny,
>
> >>> 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 Blueto=
oth
> >>> controllers. These keyboards aren=E2=80=99t able to connect to the de=
vice.
> >>> 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 =
distribution layout, the /etc directory is purely for the admin of the syst=
em. They can do localized changes. Defaults are meant to be in /usr/lib/ ac=
tually. 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 th=
at package managers / distros should only install it if they really know wh=
at they are doing. If an upgrade of a package overwrites /etc/bluetooth/mai=
n.conf 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 yo=
u 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 discussi=
on. 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/blueto=
oth/main.conf or alternatively, we actually introduce support for CONFIGURA=
TION_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 ju=
st 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 diff=
erently as mentioned above.
>
> Regards
>
> Marcel
>