meta-agl-demo - meta-agl-demo layer (demo/staging/"one-shot")

diff options

author	Scott Murray <scott.murray@konsulko.com>	2024-01-04 19:26:19 -0500
committer	Scott Murray <scott.murray@konsulko.com>	2024-01-05 16:40:12 +0000
commit	ae1ebd3ab2b5c3d5ea8ed8fc55915c070e629743 (patch)
tree	11ec593ea40e05235f6469161ec609f03c7a9ebd /classes/.gitkeep
parent	a2f890dae4d3b9d49d2921576b04384cef7641d3 (diff)

kuksa-vss-init: rework into agl-vss-helper

Rework/replace the kuksa_vss_init script with a new agl-vss-helper script that uses a configuration file for the list of VSS signals and the values they should be set to. It also will run in daemon mode if the configuration includes a list of signals to perform mocking as an actuator, and push any target values back out as the current value. This avoids needing to perform hacks around directly feeding sensor values from applications for things where we do not have an existing actuator backend (e.g. HMI units values). Bug-AGL: SPEC-5042 Change-Id: I6d1e9d5fb72f7f23a3bb45fcda0a48e1a10c3863 Signed-off-by: Scott Murray <scott.murray@konsulko.com> Reviewed-on: https://gerrit.automotivelinux.org/gerrit/c/AGL/meta-agl-demo/+/29583 ci-image-build: Jenkins Job builder account ci-image-boot-test: Jenkins Job builder account Tested-by: Jenkins Job builder account

Diffstat (limited to 'classes/.gitkeep')

0 files changed, 0 insertions, 0 deletions

# Binder Overview The ***binder*** provides the way to connect applications to the services that it needs. It provides a fast way to securely offer APIs to applications written in any language and running almost anywhere. - The ***binder*** is developed for AGL (Automotive Grade Linux) but it is not bound to AGL. - The ***binder*** is the usual name. - The binary is named **afb-daemon**. - The name **afb-daemon** stands for ***Application Framework Binder Daemon***. The word *daemon*, here, denote the fact that the ***binder*** makes witchcraft to connect applications to their expected services. (note: that usually the term of daemon denotes background process but not here). Each ***binder*** **afb-daemon** is in charge to bind one instance of an application or service to the rest of the system, applications and services. Within AGL, the connection between services and/or applications is tuned by the AGL framework and the AGL system. ## The basis of the binder The following figure shows main concepts linked to the ***binder***. <a id="fig-binder-basis"></a> ![Figure: binder basis](pictures/basis.svg) The shown elements are: - The SECURITY CONTEXT The primary intention of any ***binder*** is to provide a secured environment for any application. On AGL, the **security context** is ensured by [Smack] , the security context of the application or service. - The BINDER This is the central element. It makes possible to run HTML5 applications and provides the unified access to APIs provided by the ***bindings***. Running a pure HTML5 application doesn't require any ***binding***. In that case , the ***binder*** acts as a simple HTTP server for the web runtime. - The BINDINGs A ***binding*** adds one **API** to the ***binder***. An **API** is a set of **verbs** that can be called using either REST over HTTP or a kind of JSON RPC. ***bindings*** are either: - dynamically loaded libraries in the ***binder*** process - remote service running on the same host - remote service running on other hosts When acting as an HTTP server, the binder treats the language settings of the HTTP requests to provide internationalized content as specified by [widget specifications](https://www.w3.org/TR/widgets/#internationalization-and-localization). - The APPLICATION An ***application*** connects to the binder to get access to the **API** that it provides or to get its HTTP services to access resources.  ## Interconnection of binders The AGL framework interprets the **widget/application** manifests to setup the ***bindings*** configuration of the ***binders***. The figure below shows that ***binders*** are interconnected. <a id="fig-binder-interconnection"></a> ![Figure: binder interconnection](pictures/interconnection.svg) The figure shows 4 several **application/service**: **A**, **B**, **C** and **D**. The application **A** might use an **API** that is shown as a local ***binding*** but that in reality runs within the context of **D**. The framework AGL takes care of making the plumbing working.


context:
space:
mode: