[agl-discussions] Proposal to handle AGL metadata

Sebastien Douheret sebastien.douheret at iot.bzh
Thu Mar 22 21:51:32 UTC 2018

here is a quick proposal to address the problematic that Loïc 
encountered and that was discussed during last dev meeting.


_Typical issues that need to be addressed :_

 1. When building an application from the SDK, some build options may
    depend on the machine/platform (MACHINE variable in bitbake). By
    default this information is not available in Yocto SDK.

 2. At first boot, we may complete the runtime configuration by
    auto-detecting some hardware components: examples: MOST module on
    Kingfisher, GPS, accelerometer, ....

 3. At runtime it may also be useful to identify the particular hardware
    options of the platform. As an example, we may want to adjust
    weston.ini settings depending on the video output setup that may
    change from one boot to another.

 4. There are also production metadata that may change the behavior of
    some services (example: car model impacting CAN signals definition
    or audio system setup)

_Proposal to address these issues:_

A common solution could be to create /etc/agl-XXX files, similar to 
/etc/os-release file but specific to AGL that can be sourced by any shell.
To address the above issues, we could typically defined:

 1. /etc/agl-release :
    Contain build information like MACHINE, AGL version, AGL features,
    Yocto layer manifests, image information, ...
    This file could be available both in target image and in SDK
    sysroots / environment to ensure applications and platform consistency

 2. /etc/agl-hardware-config :
    Contain hardware setup that cannot be auto-detected.
    This file may be generated / updated from different locations :
    build time, manually by an operator, first boot...
    For example: if a MOST module is available on the Kingfisher, we can
    add a known variable into /etc/agl-hardware-config.

 3. /etc/agl-runtime-config :
    This file could be generated at each boot through udev rule or any
    detection script.
    Typical usage: detect how many screens are plugged on the board.
 4. /etc/agl-vehicle-config :
    Contain car maker metadata. For example: car model, options, VIN...

As /etc files may be read-only, the runtime files could be 
copy/generated into /run directory.

Specifically for SDK, Yocto offers an existing mechanism to extend the 
SDK environment setup based on script fragments located in sysroot (for 
example $OECORE_TARGET_SYSROOT/environment-setup.d/agl-setup.sh ).
It's easy to generate an extra script that will source the corresponding 
files (/etc/agl-XXX).

To handle those operations, we propose to add a new AGL package named 
for example agl-info.

Any feedback comments will be appreciated.

Best Regards,

sebastien.douheret at iot.bzh - www.iot.bzh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/automotive-discussions/attachments/20180322/1537a867/attachment.html>

More information about the automotive-discussions mailing list