Re: Need for offline binary configuration

Bruce Ashfield <bruce.ashfield@...>

On 12-11-20 10:09 AM, Venkata ramana gollamudi wrote:
Poky allows to build custom Linux for you, but we have cases where the post build customization is required, like user-addition, network configuration, service control. Even selecting the required packages can be a post build activity.

The current model requires the image to be rebuilt to support these configuration.
Offline Configuration tool (OCT), which allows a binary image customization before making a final target image. This case will be more evident in larger companies, where platform teams, product teams , application teams are distributed and Linux build from source will be owned and lab tested by a single team, like platform team. Other teams just configure to use it for product variants from same platform build.

Detailed use cases can be found in enhancement bug:3252

OCT should work on the binary pool of compiled packages generated from poky.

The basic operations that can be supported includes
a) Select/deselect required packages from pool of binary packages into final target image.
b) Provision to select external binary packages like ADT compiled applications as input and add them to final target image.
c) Binary level Offline configuration can includes
Configure the users/passwords
Configure the network
Configure the host name
Select the services to be started by default
Security related configuration
Generate initrd in ramfs/ext3/... format

Considering the methods to support these in our current yocto model, following changes can be done.
1) HOB can be the tool which can be extended to support these
Poky can generate a binary package pool as one if its output and Hob can work on this package pool to select packages, configure and generate image.
So HOB can support opening HOB in Binary(or OCT) mode i.e., without build options but only with binary package selection. Configuration GUI needs to be added to HOB.
Note:HOB+OCT is together or separate, needs a bit more thought and overall organization as they will be intended for different users.
Is there some overlap between this point and the other ongoing discussions
about image construction, deployment and package management ?

i.e. this thread:

[OE-core] RFC: OE-Core image creation and deployment

These may already be coordinated, but I do see some common threads and
it would be nice to make sure everything will work together and that we
aren't duplicating effort!



2) Binary package pool can be a minimal/partial sstate-cache, as complete sstate-cache is quite big and not required for product teams as they are not expected to build but just need to select and configure.
I think it is sufficient to keep the minimal binaries from sstate-cache which are required to execute image.bbclass, do_rootfs task to generate image.
3) Along with specific configuration UI implementation, a generic configuration model similar to kernel kconfig and menuconfig can be considered, in cases where more detailed offline configurations is required like detailed security configuration.

yocto mailing list

Join to automatically receive all group messages.