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.
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
inside containerPlan of K.K
Separate development platform and reference of product embedded
- Development platform
- Reusing agl-image-weston (because we need to use nested compositor architecture until DRM release manager will come)
- Introduce new layer to add-on container features on it
- add LXC support
- add container configuration for agl-ivi (for agl-demo-platform) and agl-ic (for agl-cluster-demo-platform
- link apps/services of multiple containers together
- tbtnavi of CES demo
- service only in host
- container runtime, container manager, display manager (DRM release manager / host compositor)
- server/client
- security framework/integration
- unprivileged container (LSM and capability)
- 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.
- If we use agl-image-*, dependency on appfw/SMACK is problem/challenging. There are several possible options,
- 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
- agl-image-* are still too large to certificate all packages
- refer to the VERY long term maintained source code like Redhat/CentOS/Debian)
- recipes and patches are common, identified by name, 'agl-ivi' and 'agl-ic' (default name, can be changed by variable in recipes/local.conf)
- network configuration
- use lxc-net by default (sharing host network adapter by containers to access internet)
- TBD: introduce guest pass-through (e.g. internet access permitted only to agl-ivi) and make these selectable
- very basic container manager
- To support nested compositor easily, add easy-launcher, lxc-launcher(runlxc)
- easy to select one from predefined configurations
- running 1 container, agl-ic or agl-ivi
- running 2 container, agl-ic and agl-ivi
- Because multiple monitors cannot be usable on QEMU with AGL image
- QEMU + SPICE can support multiple monitors but it requires spice-vdagent and xwayland(xserver + xrandr/Xinerama)
- not yet investigation: whether weston + xwayland can do the same above
- Reference of product embedded
- TBD