zeus updates for dragonboard-410c - meta-agl

Linux Foundation Collaborative Projects

index : meta-agl

meta-agl layer (core AGL)

Grokmirror user

summary refs log tree commit diff stats

path: root/meta-agl-profile-cluster

diff options

author	Scott Murray <scott.murray@konsulko.com>	2020-02-10 15:10:17 -0500
committer	Jan-Simon Moeller <jsmoeller@linuxfoundation.org>	2020-02-17 16:00:13 +0000
commit	5011dd3b4900cc6030d18055f2148c21b8dde7b7 (patch)
tree	998ae08b5b443d0ce8a3c2684bf5ec81f9a01660 /meta-agl-profile-cluster
parent	ffe584b58889bad79004f3916f858299d8b7b385 (diff)

zeus updates for dragonboard-410c

Changes: - Update BBMASK definition in template to avoid new warning. - Rename linux-linaro-qcomlt bbappend to use a wildcard to cover both the new 5.4 kernel in meta-qcom and still the older 4.x kernels in that BSP that a user might configure instead. Bug-AGL: SPEC-2932 Change-Id: I8a735a38409822e7069cc84bc2a42c06d351a278 Signed-off-by: Scott Murray <scott.murray@konsulko.com>

Diffstat (limited to 'meta-agl-profile-cluster')

0 files changed, 0 insertions, 0 deletions

ref='#n136'>136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344

Overview of AFB-DAEMON
======================

Roles of afb-daemon
-------------------

The name **afb-daemon** stands for *Application
Framework Binder Daemon*. That is why afb-daemon
is also named ***the binder***.

**Afb-daemon** is in charge to bind one instance of
an application to the AGL framework and AGL system.

On the following figure, you can use a typical use
of afb-daemon:

<a id="binder-fig-basis"><h4>Figure: binder afb-daemon, basis</h4></a>

	. . . . . . . . . . . . . . . . . . . . . . . . . .
	.        Isolated security context                .
	.                                                 .
	.        +------------------------------+         .
	.        |                              |         .
	.        |    A P P L I C A T I O N     |         .
	.        |                              |         .
	.        +--------------+---------------+         .
	.                       |                         .
	.                       |                         .
	.   +-------------------+----------------------+  .
	.   |                            :             |  .
	.   |        b i n d e r         :             |  .
	.   |    A F B - D A E M O N     :  BINDINGS   |  .
	.   |                            :             |  .
	.   +-------------------+----------------------+  .
	.                       |                         .
	. . . . . . . . . . . . | . . . . . . . . . . . . .
	                        |
	                        v
	                   AGL SYSTEM

The application and its companion binder run in secured and isolated
environment set for them. Applications are intended to access to AGL
system through the binder.

The binder afb-daemon serves multiple purposes:

1. It acts as a gateway for the application to access the system;

2. It acts as an HTTP server for serving files to HTML5 applications;

3. It allows HTML5 applications to have native extensions subject
to security enforcement for accessing hardware ressources or
for speeding parts of algorithm.

Use cases of the binder afb-daemon
----------------------------------

This section tries to give a better understanding of the binder
usage through several use cases.

### Remotely running application

One of the most interresting aspect of using the binder afb-daemon
is the ability to run applications remotely. This feature is
possible because the binder afb-daemon implements native web
protocols.

So the [figure binder, basis](#binder-fig-1) would become
when the application is run remotely:

<a id="binder-fig-remote"><h4>Figure: binder afb-daemon and remotely running application</h4></a>

	             +------------------------------+
	             |                              |
	             |    A P P L I C A T I O N     |
	             |                              |
	             +--------------+---------------+
	                            |
	                       ~ ~ ~ ~ ~ ~
	                      :  NETWORK  :
	                       ~ ~ ~ ~ ~ ~
	                            |
	. . . . . . . . . . . . . . | . . . . . . . . . . . . . .
	. Isolated security         |                           .
	.   context                 |                           .
	.                           |                           .
	.     . . . . . . . . . . . . . . . . . . . . . . . .   .
	.     .                                             .   .
	.     .               F I R E W A L L               .   .
	.     .                                             .   .
	.     . . . . . . . . . . . . . . . . . . . . . . . .   .
	.                           |                           .
	.       +-------------------+----------------------+    .
	.       |                            :             |    .
	.       |    A F B - D A E M O N     :   BINDINGS  |    .
	.       |                            :             |    .
	.       +-------------------+----------------------+    .
	.                           |                           .
	. . . . . . . . . . . . . . | . . . . . . . . . . . . . .
	                            |
	                            v
	                       AGL SYSTEM

### Adding native features to HTML5/QML applications

Applications can provide with their packaged delivery a binding.
That binding will be instanciated for each application instance.
The methods of the binding will be accessible by applications and
will be excuted within the security context.

### Offering services to the system

It is possible to run the binder afb-daemon as a daemon that provides the
API of its bindings.

This will be used for:

1. offering common APIs

2. provide application's services (services provided as application)

In that case, the figure showing the whole aspects is

<a id="binder-fig-remote"><h4>Figure: binder afb-daemon for services</h4></a>

	. . . . . . . . . . . . . . . . . . . . . . 
	.  Isolated security context application  . 
	.                                         . 
	.    +------------------------------+     . 
	.    |                              |     . 
	.    |    A P P L I C A T I O N     |     . 
	.    |                              |     . 
	.    +--------------+---------------+     .     . . . . . . . . . . . . . . . . . . . . . .
	.                   |                     .     .        Isolated security context A      .
	.                   |                     .     .                                         .
	. +-----------------+------------------+  .     . +------------------------------------+  .
	. |                        :           |  .     . |                        :           |  .
	. |      b i n d e r       :           |  .     . |      b i n d e r       :  service  |  .
	. |  A F B - D A E M O N   : BINDINGS  |  .     . |  A F B - D A E M O N   : BINDINGS  |  .
	. |                        :           |  .     . |                        :     A     |  .
	. +-----------------+------------------+  .     . +-----------------+------------------+  .
	.                   |                     .     .                   |                     .
	. . . . . . . . . . | . . . . . . . . . . .     . . . . . . . . . . | . . . . . . . . . . .
	                    |                                               |
	                    v                                               v
	         ================================================================================
	                                     D - B U S   &   C Y N A R A
	         ================================================================================
	                    ^                                               ^
	                    |                                               |
	. . . . . . . . . . | . . . . . . . . . . .     . . . . . . . . . . | . . . . . . . . . . .
	.                   |                     .     .                   |                     .
	. +-----------------+------------------+  .     . +-----------------+------------------+  .
	. |                        :           |  .     . |                        :           |  .
	. |      b i n d e r       :  service  |  .     . |      b i n d e r       :  service  |  .
	. |  A F B - D A E M O N   : BINDINGS  |  .     . |  A F B - D A E M O N   : BINDINGS  |  .
	. |                        :     B     |  .     . |                        :     C     |  .
	. +------------------------------------+  .     . +------------------------------------+  .
	.                                         .     .                                         .
	.        Isolated security context B      .     .        Isolated security context C      .
	. . . . . . . . . . . . . . . . . . . . . .     . . . . . . . . . . . . . . . . . . . . . .


For this case, the binder afb-daemon takes care to attribute one single session
context to each client instance. It allows bindings to store and retrieve data
associated to each of its client.

The bindings of the binder afb-daemon
------------------------------------

The binder can instanciate bindings. The primary use of bindings
is to add native methods that can be accessed by applications
written with any language through web technologies ala JSON RPC.

This simple idea is declined to serves multiple purposes:

1. add native feature to applications

2. add common API available by any applications

3. provide customers services

A specific document explains how to write an afb-daemon binder binding:
[HOWTO WRITE a BINDING for AFB-DAEMON](afb-binding-writing.html)


Launching the binder afb-daemon
-------------------------------

The launch options for binder **afb-daemon** are:

	  --help

		Prints help with available options

	  --version

		Display version and copyright

	  --verbose

		Increases the verbosity, can be repeated

	  --port=xxxx

		HTTP listening TCP port  [default 1234]

	  --rootdir=xxxx

		HTTP Root Directory [default $AFBDIR or else $HOME/.AFB]

	  --rootbase=xxxx

		Angular Base Root URL [default /opa]

		This is used for any application of kind OPA (one page application).
		When set, any missing document whose url has the form /opa/zzz
		is translated to /opa/#!zzz

	  --rootapi=xxxx

		HTML Root API URL [default /api]

		The bindings are available within that url.

	  --alias=xxxx

		Maps a path located anywhere in the file system to the
		a subdirectory. The syntax for mapping a PATH to the
		subdirectory NAME is: --alias=/NAME:PATH.

		Example: --alias=/icons:/usr/share/icons maps the
		content of /usr/share/icons within the subpath /icons.

		This option can be repeated.

	  --apitimeout=xxxx

		binding API timeout in seconds [default 20]

		Defines how many seconds maximum a method is allowed to run.
		0 means no limit.

	  --cntxtimeout=xxxx

		Client Session Timeout in seconds [default 3600]

	  --cache-eol=xxxx

		Client cache end of live [default 100000 that is 27,7 hours]

	  --sessiondir=xxxx

		Sessions file path [default rootdir/sessions]

	  --session-max=xxxx

		Maximum count of simultaneous sessions [default 10]

	  --ldpaths=xxxx

		Load bindings from given paths separated by colons
		as for dir1:dir2:binding1.so:... [default = $libdir/afb]

		You can mix path to directories and to bindings.
		The sub-directories of the given directories are searched
		recursively.

		The bindings are the files terminated by '.so' (the extension
		so denotes shared object) that contain the public entry symbol.

	  --binding=xxxx

		Load the binding of given path.

	  --token=xxxx

		Initial Secret token to authenticate.

		If not set, no client can authenticate.

		If set to the empty string, then any initial token is accepted.

	  --mode=xxxx

		Set the mode: either local, remote or global.

		The mode indicate if the application is run locally on the host
		or remotely through network.

	  --readyfd=xxxx

		Set the #fd to signal when ready

		If set, the binder afb-daemon will write "READY=1\n" on the file
		descriptor whose number if given (/proc/self/fd/xxx).

	  --dbus-client=xxxx

		Transparent binding to a binder afb-daemon service through dbus.

		It creates an API of name xxxx that is implemented remotely
		and queried via DBUS.

	  --dbus-server=xxxx

		Provides a binder afb-daemon service through dbus.

		The name xxxx must be the name of an API defined by a binding.
		This API is exported through DBUS.

	  --foreground

		Get all in foreground mode (default)

	  --daemon

		Get all in background mode


Future development of afb-daemon
--------------------------------

- The binder afb-daemon would launch the applications directly.

- The current setting of mode (local/remote/global) might be reworked to a
mechanism for querying configuration variables.

- Implements "one-shot" initial token. It means that after its first
authenticated use, the initial token is removed and no client can connect
anymore.

- Creates some intrinsic APIs.

- Make the service connection using WebSocket not DBUS.

- Management of targetted events.

- Securisation of LOA.

- Integration of the protocol JSON-RPC for the websockets.


context:
space:
mode: