The current mechanism for handling /lib/firmware was always a copy and
sync from dom0 -> essential. This is problematic for the case of a
read-only root file system or a top level volume which uses slow media
backed with nonvolatile storage.
The read-only rootfs support added the ability to mount the
/opt/container volume early in the boot cycle which allows us to make
the optimization that we can have just a single copy of the firmware
in the dom0 container and avoid the complexity of syncing. This is in
the new default. Should a particular use case warrant syncing the
firmware to the /var/lib/cube/essential/lib/firmware directory all
that is needed is to break the link.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
We have added a new container to the OverC framework to handle
networking services for the cube-lan. Although this functionality has
been available since commit ad749f0c06 [cube-vrf: Introduce the
cube-vrf container], we have yet to include it in documents and system
scripts. Add references to cube-vrf where needed.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
In commit 7132ee0f30 [images: bump essential PV and remove dom1] we
removed dom1 from the OverC framework. However, several references to
dom1 remained which we are now removing.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
This adds a systemd system container image which allows for the
creation of 1 systemd system container image using local.conf
variable(s), without the need to touch any recipe files. As described
in the included README the use of an .inc file will allow users to
create additional systemd system container images with only a few
lines in a new image recipe file.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
This adds a simple app container image which allows for the creation
of 1 app container image using only a local.conf variable, without the
need to touch any recipe files. As described in the included README
the use of an .inc file will allow users to create additional app
container images with only a few lines in a new image recipe file.
Eventually I would like to have a 'universal' app image which can
allow the building of any application (for which there is a recipe)
into its own container image, without the need to create image
recipes. This is the first (needed) step toward getting to this goal.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Currently we ship the linux-firmware in -essential this offers some
direct and indirect challenges.
The direct challenges are that the size of -essentially is almost
double what it can be without the firmware include, additionally the #
of reasons to require an update to -essential is greater with the
firmware included.
An indirect challenge is that dom0 will have to interact with
-essential's rootfs should a container wish to add kernel firmware to
the system.
By using the 'bridge' filesystem (/var/lib/cube/essential) and
shipping the firmware in dom0 we can offer solutions to the above
challenges. We remove the added size of firmware in the -essential
fileystem (and images), we affect firmware updates by updating dom0
and dom0 can contribute to firmware by simply manipulting its own
filesystem.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
As we are evolving fast, we need documents for others to getting
started quickly without reading the whole code base. So create a
document directory and put an unprivileged container document in.
Signed-off-by: Feng Mu <Feng.Mu@windriver.com>
