Received-SPF: pass (google.com: domain of linux-bluetooth+bounces-4783-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Precedence: bulk
MIME-Version: 1.0
References: <20240516193836.228281-1-arun@asymptotic.io> <20240516193836.228281-2-arun@asymptotic.io>
 <CABBYNZLriw3OMX_oNA84FohCp20i0zeskZn9MZGOD5qg=EaPEg@mail.gmail.com>
In-Reply-To: <CABBYNZLriw3OMX_oNA84FohCp20i0zeskZn9MZGOD5qg=EaPEg@mail.gmail.com>
From: Arun Raghavan <arun@asymptotic.io>
Date: Fri, 17 May 2024 14:39:19 -0400
Message-ID: <CAN03qa_TgFEA7hCXKH1JfUMCBkotqLHkrX=W1+p-UvakRGiv7Q@mail.gmail.com>
Subject: Re: [PATCH BlueZ,v6 1/5] src/shared: Add initial implementation for
 an ASHA profile
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: linux-bluetooth@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"

Hey Luiz,

On Fri, 17 May 2024 at 10:23, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
[...]
> This is not quite right, we can't depend on libbluetooth since that is
> GPL also both adapter.h and device.h, or any header that adds btd_
> APIs, are probably only meant for use in bluetoothd internals, usually
> that means that the connection setup, socket handling etc, needs to be
> done at the plugin side and then attached to the bt_asha instance as a
> pure file descriptor then you can manage it via io handling.

I'm not sure I follow how the code is meant to be structured. Is there
any documentation or something I can read up on?

As I understand it, you're saying anything that relies on btd_* calls
should be inside profiles/audio/..., and not in src/shared/...

In this case, all the GATT bits will need to move back to
profiles/audio/asha.c, and there's not much left in src/shared/asha.c
that would be useful, which would leave things similar to v1, where
everything was in profiles/audio/

Cheers,
Arun