...

Another limitation in lxc-container is that network interface (brlan0) cannot be created by process (gwprov_utopia) running inside container . Only host has permission to create network interface through host based process. This creates bottleneck for RDKB containerization, since it creates bridge interface (brlan0) for LAN

...

Since CCSPPandM uses utopia which in turn uses shared memory through pre-defined API's. gwprov_utopia running inside CCSPPandM container will populate some of the base information in shared memory

Image Modified

So to avoid CCSPPandM design change in the way it is accessing shared memory for provisioning, gwprov_utopia and CCSPPandM are needed to run in same container

...

lo interface is used ( using loop back address 127.0.0.1 ) for the above mentioned IPC which is mapped into CcspPandM container as well

Image RemovedImage Added

lxc has support to map interfaces in host to container. Once interface is created in host, it is reflected in CcspPandM too which can be bring to up state based on other events from gwprov_utopia running in ccsppandm container as well

...

Following components are expected to run under respective container using the UID and GID settings and as secure container provided from XML file during build time 

• D-BUSDBUS
• CCSPCR
• CcspPandM CCSPPANDM ( + gwprov_utopia )
• PSMSSP
• CCSPWIFI

D-BUS Design approach based on LGI

Since dbus uses system_bus_socket file for inter process communication between ccsp components

So when D-Bus moved into container this file cannot be accessed by other container components considering the limitation of shared memoryin accessing file between containers

Hence, D-Bus container is executed by creating symbolic link for system_bus_socket file in host, which is used by containers which needs d-bus communication

It is again design philosophy is Design philosophy states that d-bus communication is used for IPC as native RDKB design for IPC which in RDKB Architecture but it has pre defined capabilities

System Diagram

Following is the flow which will bring the RDKB components running under container to up state as a system on whole

Service file for bringing RDKB components as container which is invoked by host as part of systemd .

This is similar to previous design except change in service file to call container based script files

Host: init->systemd service->gwprov_utopia+lxcserver (for IPC between CcspPandM)

Container: DBUS->CCSPCR->PSMSSP->CCSPPandM(+ gwprov_utopia)

Please refer to user manual for commands to be used for handling containers and processing application inside container

Below mentioned diagram will differentiate the RDKB system before and after containerization

RDKB System running in Host 

Image Added

RDKB System running in Containers

Image Added

Enhanced Support for Interface Creation

Workflow

Containers Workflow Diagram

Image Added

All containers follow the same Workflow procedure.

The application and utilities inside rootfs will vary based on each container's role.This way of IPC communication cannot be used for other IPC scenarios mentioned earlier in this document