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
etc..
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.
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.
Regards,
Ramana
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
