agl-service-ddm

Some changes were merged to gerrit in 2020.  Closing due to inactivity since then. 

ATM, we only try to detect main interfaces/controllers: wifi, ethernet, bluetooth but there's no enumeration of (hot)plugged devices. To solve this, we probably need to look at udev and how to interpret udev events. We'd also need a "live" tree for the registry, not only something initialized from plain files at startup...

when device scanning on runtime starts, many devices with different "subsystem", "device type" are detected, but we are interested in just a group of them like connectivity and multimedia devices. Do you have any list of desired "subsystem", "device type" or any other udev devices property or attributes to filter the devices effectively?

Thank you, Stephane for detailed descriptions!
Absolutely "agl-service-platform-info" is the way to start! ... It can fulfill the features "3", "4" and give the capability to implement features "1", "2" and "5".
We can create another JSON file for devices to avoid rewrite static build JSON tree data structures as you did with the scripts, then we can set the devices last list with their state and notify subscribers for the state changes.
The features number "1" and "5" and part of the feature "2" are beyond the "device detection management" scope and as I am planning for them, I can see some major changes need to be done therefore require another Jira ticket, maybe an Epic one because some of those changes and features need to be implemented throughout the AGL and virtually they can be considered as "Architectural" decisions thus they would be presented and discussed in SAT-EG maybe.
By now, I start working on "agl-service-platform-info" for "hot-plugged devices detection" then we can decide on the next steps.

Hi Farshid,

We already have some parts that may help.

First hint: IoT.bzh pushed the service 'platform-info' 18 months ago here:

https://git.automotivelinux.org/apps/agl-service-platform-info/

It provides an interesting starting point: it's a kind of "registry" (a tree with values on leaves) to query platform information. Information is stored as JSON files parsed at service startup in /etc/platform-info. The service is very simple: it reads all json files located in /etc/platform-info/*.json and proposes an API to retrieve the key/values stored in each file.

It's not used for demos as everything is more or less designed (= read 'hardcoded' ...) for the well known boards and demo machines, but it's definitely a must-have if you want to create a service where implementation depends on hardware platform or hw capabilities detected at runtime.  It's very easy to use and makes a good abstraction of the platform details

In recent images (master), it's ready for systemd activation but it's not started as no other service/app requires it. To start it manually:

Then you can check the log:

You can finally query the API directly with afb-demo-client to make some tests (adjust the port: it's not always 30020!) :

Second hint: the file 'build.json' in /etc/platform-info is prepared at build time to describe static platform information (check the content of /etc/platform-info/build.json). On h3ulcb with KF, I get:

Third hint: at IoT.bzh, we developed some scripts to handle runtime detection of core platform functionalities and devices. The scripts and detailed information are located here:
https://github.com/iotbzh/platform-runtime-tools

but they're not integrated into standard AGL images. (see and related tasks)

They are preinstalled in AGL image (agl-demo-platform) if you build AGL using our layer meta-iot-bzh/meta-custom . Recipe is here:
https://github.com/iotbzh/meta-iot-bzh/tree/master/meta-custom/recipes-platform/platform-runtime-tools

As a summary, the package pr-tools adds some scripts and scriptlets triggered by early systemd services to create some extra information file in /etc/platform-info. For KF, we get the following extra files:

The first file core.json contains some base runtime information, not subject to change over time, like SoC ID, SoC vendor, GPU etc. Currently, the script that creates the file is triggered at each boot but it could be probably run once for all at first boot only.

The second file devices.json is run at each boot and tries to detect the various devices and interfaces: BT, CAN, Wifi, Ethernet, ... More can be easily added. But this is a one shot detection for non-hotplug devices.

As a summary, on my H3+KF platform running IoT.bzh image, I get the following platform-info tree:

Note: the current binding merges all the JSON files located in /etc/platform-info to provide a single key/values tree but IMO it should be prefixed by a node representing the origin file (a kind of 'section'). The key path would then be really unique and it would be harder to have collisions: we would query "core.soc_id" or "build.machine" or "devices.ethernet_devices".

Fourth hint: to handle hotplug devices gracefully, one way could be to listen to udev events and maintain an up-to-date file in /run/platform/platform-info/hotplug.json. The binding agl-service-platform-info would then have to get notified from the changes on the file and reload it. Another solution could be to listen directly to udev events from the platform-info binding but the logic to handle events and maintain the registry has to be written in agl-service-platform-info.