[yocto] RFC: Post build configuration

[Sean Liming]

My apologies for top loading. I spotted this e-mail from last week, but I
couldn't response until now. Is this an active effort to apply settings to a
distribution or just a proposal? 

 

The reason I ask: it would help developers new to Embedded Linux like myself
easily configure the image with the necessary settings to create the image
without having to dig through different scripts.  In Windows Embedded
Standard the development tools allow the developer to pre-define settings
like user names, password, computer names, Time zone, applications to launch
on startup, etc. The attached JPG file shows how settings are pre-defined in
WES' Image Configuration Editor. The goal is to pre-define as much as
possible in order to automate the build process and limited post image
create steps. The automated build is very desirable for medical and
government customers. Hob could have something similar.

 

Along with the other settings that are listed below, could the post build
setting applications be configured to launch on startup?

Why post-build instead of pre-build?

 

Regards,

 

Sean Liming

 

From: yocto-bounces at yoctoproject.org [mailto:yocto-bounces at yoctoproject.org]
On Behalf Of Venkata ramana gollamudi
Sent: Friday, March 29, 2013 5:17 AM
To: yocto at yoctoproject.org
Cc: Sanil kumar
Subject: [yocto] RFC: Post build configuration

 

This is in reference to my previous post regarding post build configuration,
with few points re-iterating to set the ground.
 https://lists.yoctoproject.org/pipermail/yocto/2012-November/012867.html

 

"Post build" configuration and need for configuration platform/model:

 

    There have been several discussions regarding need for image format,
file system and disk configuration, network, users addition etc. Most are of
these features are configurable in other distributions like opensuse, fedora
during the image installation on the target. Considering the Embedded Linux
distribution scenario, these features can be configured offline and the
generated image can be directly deployed on the target.

 

Example configuration options that can be supported include
    Configure the users/passwords
    Configure the network
    Configure the host name
    Select the services to be started by default
    Security related configuration
    Configure image formats ramfs/ext3/... paritions,disk management etc
    Serial port configuration
    etc..


Also a userscenario include
    Offline Binary Configuration, 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.

 

As configuration needs and options vary based on packages/features selected
during for the distribution, so there is a need for a configuration
platform/model

1) which allows new configuration options can be added easily and each
package/distribution knows how it can be configured, so that selection of
package or feature will expose those configuration options to the user.

2) Tools like HOB and Webhob also need a clean configuration interface to
configure the image. 
3) This can be extended to support Generic configuration UI like kernel
menuconfig.

 

 

Considering the above Post build configuration in mind, I like to put
forward a model (high level flow) detailing 

1. How the configuration functions/logic are maintained in poky?

2. How is configuration functions shipped along with image?

3. How configuration functions are used by configuration tool(s) to apply
them over binary image, based on user configuration inputs?

 

1. How the configuration functions/logic are maintained in poky?

----------------------------------------------------------------------------
-------

 

    Various configuration functions supporting the distribution
configuration needs are maintained in current poky layers.
    a) Configuration functions include Image level and package level
configuration functions. Where package level configuration functions kept
along with package recipe(say pkgname_version.cfg). 
    b) Package level configuration functions can override the image level
configuration functions. 
        Example: Useradd logic need to be different, if busybox is selected
or if pwdutils package is selected.
    c) Each layer can override configuration functions, just like bb files.
    d) Menu Definition Information contains the metadata about configuration
functions and their parameters allowing it to represent it in Generic UI, is
also kept along with configuration functions. Menu definition Information
can be represented in Menu Definition Language (MDL, say xml based). 

 

2. How is configuration functions shipped along with image?

----------------------------------------------------------------------------
-

   Configuration Library (ConfigLib) is created from configuration functions
and MDL (from step1) during the package build time. ConfigLib is based on
build time packages and features selected. This configuration Library is
added to package feed.

 

3. How configuration functions are used by configuration tool(s) to apply
them over binary image, based on user input/need?

----------------------------------------------------------------------------
----------------------------------------------------------------------------
-----------

   New tool can be created or existing tool(s) can be extended to support
Post build package selection, image generation and configuration. Its
functionality includes

    a) Selection of packages from package feed.
    b) Install the selected packages to relocatable rootfs.
    c) Copy configuration functions corresponding to selected packages from
ConfigLib to SelectedConfigLib.
    d) User can configure the image by 
        - Manually modifying offline configuration file (oct.conf)
        - Using a generic configuration UI which generates offline
configuration file (oct.conf)
    e) Tool reads the offline configuration file(oct.conf) and maps the user
configuration inputs to configuration functions in SelectedConfigLib.
       It applies the configuration options on the extracted rootfs by
executing respective configuration functions.


We are in the process of initial design and prototyping this model, soon it
will be shared. Looking forward this feature as part of yocto1.5.

 

Note: This RFC specifically discuss about "post build binary configuration",
but not pre-build or build level configurations.

    
Regards,

Ramana

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20130404/09462c4c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WES settings.JPG
Type: image/jpeg
Size: 179394 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20130404/09462c4c/attachment.jpe>