Introduction

The use of AGL UCB integration can be divided into two main categories.

• development platform for innovation, which means individual features and components, as well as prototyping and demo/PoC development
  • It is preferable to reuse the existing AGL UCB (including the demo implementation), because the other will be developed from scratch and will not be available for some time.
• integrate reference system which is baseline of product embedded
  • This will be a minimally configured system, which makes it very difficult to use for development purposes, such as new features and components.

Abstraction

Development platform

Maximum reuse of existing AGL UCB

GOAL: provision of development platform

• for Innovation
• for development new features/component as SDK

Use case of development

1.  inside container
   1. develop applications/services
   2. integrate packages inside container
      • agl-demo-platform, agl-cluster-demo-platform
2. between containers
   1. link apps/services of multiple containers together
      • tbtnavi of CES demo
3. inside host
   1. service only in host
      • container runtime, container manager, display manager (DRM release manager / host compositor)
4. between host and container 
   1. server/client 
   2. security framework/integration
      • unprivileged container (LSM and capability)
   3. management of devices
      • hotpluging
      • pass through
      • sharing

Reference Integration of Product development's baseline

New integration from scratch? (T.B.D)

GOAL: Reference QM implementation to embedded product system

It is preferable to start with a minimum configuration, core-image(QM) and add-on (either QM or Non-QM)

• core image for QM
  • all packages should be certificated by AGL development process
  • existing minimal image are large
    
    • agl-image-* are still too large to certificate all packages
      • If we use agl-image-*, dependency on appfw/SMACK is problem/challenging.  There are several possible options,
        • Remove appfw and/or SMACK dependency
        • Accept them as third party (existing) OSS and certificate them by ICE development process
        • Re-implement them following the ICEG development process.
    • poky/core-image-minimal is still large but If we can categorize packages that require certificated and those that don't, might be able to use
    • poky-tiny and other small distributions are under investigation
  • refer to the VERY long term maintained source code like Redhat/CentOS/Debian