Received-SPF: pass (google.com: domain of linux-bluetooth+bounces-1408-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240125-rm-ext-plugins-v3-0-d141f7870bb6@gmail.com>
 <CAAEJBhKW3XZCZiz6MZ8NbCW61iU0gxL_LGru5y0Ubb_hbGAt_g@mail.gmail.com>
 <CACvgo50AWHGmYdRRLjq7ki=+FQ2J_YQq4JDg0PZATxorEjwccg@mail.gmail.com> <CABBYNZLx1DVkXQgDXbLZPCEawQR4kBNfOo8q9KCG=MGw9xnjkg@mail.gmail.com>
In-Reply-To: <CABBYNZLx1DVkXQgDXbLZPCEawQR4kBNfOo8q9KCG=MGw9xnjkg@mail.gmail.com>
From: Emil Velikov <emil.l.velikov@gmail.com>
Date: Fri, 26 Jan 2024 15:43:25 +0000
Message-ID: <CACvgo52Ze+sDcZUhKc90JAUjPVcubwNQ4Cksvv8F9xeCezJzWg@mail.gmail.com>
Subject: Re: [PATCH BlueZ v3 0/8] Remove support for external plugins
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: Szymon Janc <szymon.janc@codecoup.pl>, linux-bluetooth@vger.kernel.org, 
	Emil Velikov <emil.velikov@collabora.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Luiz,

On Thu, 25 Jan 2024 at 18:30, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
>
> Hi Emil,
>
> On Thu, Jan 25, 2024 at 8:51=E2=80=AFAM Emil Velikov <emil.l.velikov@gmai=
l.com> wrote:
> >
> > On Thu, 25 Jan 2024 at 13:02, Szymon Janc <szymon.janc@codecoup.pl> wro=
te:
> > >
> > > Hi,
> > >
> > > On Thu, 25 Jan 2024 at 01:07, Emil Velikov via B4 Relay
> > > <devnull+emil.l.velikov.gmail.com@kernel.org> wrote:
> > > >
> > > > Hello everyone,
> > > >
> > > > Here's v3 fixing a small bug with the previous patches, which was
> > > > tripping the CI.
> > > >
> > > > Link to the previous revision can be found below.
> > >
> > > Just a comment that external plugins support was added to avoid udev
> > > dependency (from sixaxis) in bluetoothd.
> > > (not that I have strong opinion on this, just a note, I don't remembe=
r
> > > exactly why it was done, maybe Marcel recalls?)
> > >
> >
> > Thanks, I may have some ideas why.
> >
> > About 10 years ago (or so) some distributions were shipping
> > libudev.so.0 while others libudev.so.1. The ABI break was minimal,
> > although it was a thing.
> > I remember us doing all sorts of hacks in Mesa trying to pick the
> > correct one, esp when your system can have .1 while the game (or its
> > chroot-like environment) has .0 and vice-versa.
> >
> > I would imagine a similar issue was observed in bluez - but I can only
> > speculate.
> >
> > Over the last 5+ years, literally all supported distributions have
> > moved for libudev.so.1 and the Steam games (and runtime) has both with
> > some compat quirks to avoid explosions.
>
> I was considering applying this week but if you want to respin this
> set to sort out the dependency Im fine with, but I don't think it
> would hurt to have a libudev dependency provide we have some means to
> disable it in case the system don't intend to support sixaxis plugin.
>

I don't think I follow: what do you mean with "sort out the dependency"?

Sixaxis is no different to midi where it a) pulls a third-party
library (udev vs alsa) and b) it can be disabled at build. Technically
one can dlopen/dlsym libudev.so, although that should probably be
deferred until needed IMHO.

Thanks
Emil