search

zarhus / zarhus-issues

The Zarhus issues tracker
1 stars 0 forks source link

Building process enhancement #10

Open DaniilKl opened 1 month ago

DaniilKl commented 1 month ago

Currently documentation describes the final Zarhus OS image file in the following way:

IMAGE_NAME-IMAGE_TYPE-MACHINE_NAME.rootfs.wic.gz

With following note:

    Replace `MACHINE_NAME` with the name of the machine you have built the image
    for, `IMAGE_TYPE` with `debug` or `prod` and `IMAGE_NAME` with the name of
    the image you have built.

The MACHINE_NAME, IMAGE_TYPE and IMAGE_NAME` were added for better image configuration in future, but for now these are not used properly, and, therefore, not documented as well.

The idea was to provide a set of images (choosing which to build by specifying the IMAGE_NAME) which will provide some functionalities separately from the other, e.g. to have separate images for Secure Boot (only), Encrypted Storage (only), OTA (only) , etc., and let the users built the images for a set of machines (configured by the MACHINE_NAME) which every image has support for. So, the users can experiment with every functionality like in its own sandbox, and, if they want, build an image which will contain not one but a list of functionalities (we could add a guide on how to do so).

And finally the IMAGE_TYPE. This will be empty or have value debug, which will pollute every image with rich debug functionalities.

DaniilKl commented 1 month ago

Additionally I would consider reworking of building commands. If the above propositions are accepted we could also rework the way users will provide the configuration to build. For now a separate .yml file is used to configure build for every IMAGE_NAME, IMAGE_TYPE and MACHINE_NAME, but the scalability of this solution is questionable in case of large amount of images and platforms: the amount of config files will be IMAGE_NAME x MACHINE_NAME x 2 (IMAGE_TYPE is either empty or "debug").

kas-container has a CMD option --target which overwrites MACHINE BitBake variable, so we can provide MACHINE_NAME by a command line parameter, in this case we could decrease amount of config files to IMAGE_NAME x 2.

I wonder if it is possible to provide IMAGE_NAME and IMAGE_TYPE via command line parameters too.

DaniilKl commented 1 month ago

Wait a second, does --target specify the image name, not the MACHINE? Need to check this...

tym2k1 commented 1 month ago

As you mentioned this solution wouldn't scale all that well. I'm more in favour of having a completely modular .yml system as in commits: https://github.com/zarhus/meta-zarhus/pull/18/commits/67c2b22fe583981582124bb9a7284d83c7105cef and https://github.com/zarhus/meta-zarhus/pull/18/commits/c95301e01de6843719c90c4ae494db1db25cd978. In case if some feature is unsupported on some platform eg. RPi4 not supporting TEE we should use the COMPATIBLE_MACHINE variable