Request: Stable common identifier in /etc/os-release for QLI platforms

[pallav-qcom]

Hi,
I’m from the Snapdragon Profiler (SDP) tool team. SDP supports multiple platforms including Android, Linux, QNX, and Windows.
To reliably detect Linux-based QLI platforms, we depend on a unique and consistent identifier in /etc/os-release (for example, a common string such as "Qualcomm Linux").
Currently, we are observing inconsistent /etc/os-release content across QLI releases, which forces us to update our platform‑detection logic repeatedly.

Current /etc/os-release output
ID=qcom-distro
NAME="QCOM Reference Distro with Wayland"
VERSION="2.0"
VERSION_ID=2.0
PRETTY_NAME="QCOM Reference Distro with Wayland 2.0"
CPE_NAME="cpe:/o:openembedded:qcom-distro:2.0"

Older /etc/os-release output (≈ 6 months ago)
ID=qcom-wayland
NAME="Qualcomm Linux"
VERSION="1.5-ver.1.0"
VERSION_ID=1.5-ver.1.0
PRETTY_NAME="Qualcomm Linux 1.5-ver.1.0"
CPE_NAME="cpe:/o:openembedded:qcom-wayland:1.5-ver.1.0"

Problem

• Key fields such as ID and NAME change across releases.
• This results in non‑stable platform identification for tooling.
• SDP must be updated each time these values change.

Request
Could we have a stable and common identifier (for example, a consistent NAME or a dedicated field/value) across all QLI Linux platforms to enable reliable tool detection?
Please let me know if any additional details are required from our side.

Thanks!

[lumag]

Why do you need to ideintify QLI in some way? Way are going to ship several flavours of Yocto, one or more Debian images, etc.

[pallav-qcom]

From the Snapdragon Profiler (SDP) tooling perspective, identifying QLI is not intended to differentiate between Yocto, Debian, or other Linux distributions. Rather, it is required to reliably determine whether the connected target is a Qualcomm Linux–based platform, as opposed to a generic upstream Linux system.
As mentioned earlier, SDP supports multiple platforms—including Android, Windows, QNX, and Linux. When a device is connected, SDP must first identify the platform type in order to load and deploy the appropriate platform‑specific service libraries needed for profiling components such as GPU, CPU, and graphics APIs.

Having a reliable way to identify Qualcomm Linux ensures that SDP can:

• Select the correct platform services automatically
• Enable the appropriate profiling features
• Avoid mis‑detection or manual user configuration

Happy to align on what identifier or mechanism makes the most sense from your side. Let us know your thoughts or preferred approach.

[lumag]

What is the difference between QLI Debian and me running generic Debian image (or yocto's genericarm64 image) on the Qualcomm platform?

[pallav-qcom]

QLI Debian is not just “Debian running on Qualcomm hardware.”
It is a Qualcomm‑integrated Linux platform where the OS, kernel, drivers, firmware, and user‑space components are validated and aligned with Qualcomm silicon and software stacks.

Running a generic Debian (or Yocto genericarm64) image on a Qualcomm platform may boot and work at a basic level, but it typically lacks Qualcomm‑specific enablement, integrations, and guarantees that tools and workloads depend on.

[vkraleti]

As I understand it, the request is to ensure that the DISTRO_NAME remains consistent between QLI 1.x and QLI 2.x. I have submitted 153 to align the current naming with the convention used in QLI 1.x.

[lumag]

So, what is the difference for your software?

[ndechesne]

I think this is a really good discussion to have. I would love for our tools to work well on any of potential ways of running linux on qcom hardware. like @lumag is asking I think we need to understand what are the low level features you need, or configurations knob that SDP depends on, rather than relying on just the distro name.

[ricardosalveti]

We should not depend on /etc/os-release, as this will change based on the distro used (debian or yocto-specific distros). Also, we do expect customers to have all the qualcomm-specific enablement available as part of their own image, and that for sure won't be reflected in /etc/os-release, so we do need to find a different mechanism here.

Remember, meta-qcom-distro is our reference distribution, and we do expect customers to create their own distros based on their own needs, so we can't depend on what qcom-distro provides to decide if something should or shouldn't be compatible with the target OS.

[ricardosalveti]

@pallav-qcom what do you need to know from the OS to decide if you are compatible or not with it?

[pallav-qcom]

First of all, thank you everyone for contributing to this discussion. Since SDP supports multiple platforms and OS types, we’re trying to establish a reliable way to identify the underlying platform. We deal with several Linux variants, including automotive devices (for which SDP currently maintains separate service libraries). Based on my experience working across multiple Qualcomm chipsets and platforms, checking /etc/os-release has been the quickest way for us to identify a Qualcomm Linux environment.

Ultimately, SDP service libraries depend on the presence of Adreno(GPU) drivers, but the driver file names tend to be common across different OS variants, so driver‑only detection isn’t always reliable.

As an example, for Android we use a simple check such as:
env | grep ANDROID_ROOT

For a long‑term solution, we are open to refining the approach so that platform detection is based on capabilities rather than distro naming.

[lumag]

Ultimately, SDP service libraries depend on the presence of Adreno(GPU) drivers, but the driver file names tend to be common across different OS variants, so driver‑only detection isn’t always reliable.

That's a nice pointer. Even inside QLI we have open-source builds, which don't provide Adreno GPU drivers and use freedreno drivers from Mesa. Moreover, both sets of binaries can be present in the target rootfs with just one being selected at a runtimg. The correct way to detect the GPU driver is to check the GL renderer string (in case of GL apps) or check the selected Vulkan device (in case of Vulkan apps).

For a long‑term solution, we are open to refining the approach so that platform detection is based on capabilities rather than distro naming.

Could you please describe, which parts of the stack / platform are you actually depending or utilizing?

[pallav-qcom]

I'm trying to understand what's the relevance of stack/platform here.

The first step is that SDP launches on the host machine (for example, an x64 Windows system) and enumerates all devices connected over ADB (adb devices). For each detected device, SDP needs to determine the platform type — Android, QNX, Linux, or Automotive Linux.

Each platform has its own service libraries, which are built against that platform’s specific SDK and dependencies, and those binaries must run on the corresponding target OS. Because of these differences in dependencies, runtime libraries, and integration points, identifying the correct platform is an essential part of SDP’s initialization.

Since, we already have identifiers like “QCOM” in /etc/os-release, I thought changing to "Qualcomm Linux" would be straight forward, as older QLI uses "Qualcomm Linux" and based on that platform-logic change made into SDP

My questions are:

• If /etc/os-release is not reliable, is there any other file or identifier we can check to confirm that the device is running a Qualcomm Linux distro?

• What should SDP query from the OS to accurately determine the platform type (Android, QNX, Linux, Automotive Linux), independent of distro naming?

[lumag]

Leaving Android and QNX aside (they are distinctive enough to be detected), what is the difference between Linux and Automotive Linux?

[pallav-qcom]

Nothing much, different linux version and Adreno binaries also get build differently, due to that we need to maintain separate service libs in SDP for automotive as of now.

To detect Automotive platform also, we look for string like agl, auto in /etc/os-release