Hi,
My company wants to release a product where the BlueZ daemons are running as a host subsystem (both bluetoothd and bluetooth-meshd). So the product needs to be qualified.
I have looked on the web-page and searched in the archive of this mailing list but didn't really find any up-to-date information about this. So I wanted to ask if you have some new information that could help.
What are the general guidelines to qualify a product that is using the BlueZ stack? Is there a version that is already qualified that can be referred to? Or is the best way to qualify it ourselves using PTS testing?
Thank you and best regards,
Isak
Hi Isak,
On Mon, Jun 27, 2022 at 5:32 AM Isak Westin <[email protected]> wrote:
>
> Hi,
>
> My company wants to release a product where the BlueZ daemons are running as a host subsystem (both bluetoothd and bluetooth-meshd). So the product needs to be qualified.
> I have looked on the web-page and searched in the archive of this mailing list but didn't really find any up-to-date information about this. So I wanted to ask if you have some new information that could help.
> What are the general guidelines to qualify a product that is using the BlueZ stack? Is there a version that is already qualified that can be referred to? Or is the best way to qualify it ourselves using PTS testing?
Upstream don't qualify BlueZ by itself, usually it is the individual
companies that qualify it based on the kernel and userspace version
they intend to use. That said we do want to properly support the likes
of auto-pts with BlueZ to automate the process of qualifying with PTS,
and perhaps in the future even use it with our CI if we managed to
emulate the PTS environment inside github.
@Tedd Ho-Jeong An can you update Isak where we stand regarding using
auto-pts with BlueZ?
--
Luiz Augusto von Dentz