Re: [yocto] Multiple images on the same hardware

[Mike Looijmans <mike.looijmans@topic.nl>]

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijmans@topic.nl
W: www.topic.nl

Please consider the environment before printing this e-mail
On 31-01-2024 23:07, Aleksandar Nikolic via Lists.Yoctoproject.Org wrote:
>     Instead of a distro or machine for each combination, it's also possible to
>     use a configuration file in the build directory. Your application recipe
>     just says "require my-app-config.inc" and then you can provide the
>     contents of that file when preparing the build. Makes things easy to
>     produce but harder to reproduce...
> 
> An interesting approach, didn't occur to me, thanks for the hint.
> 
>     The penalty for building things with unneeded features usually isn't that
>     big, so it might be worth it if you have systems with and without screen
>     to build them all with "x11" or "wayland" in their distro features. Trick
>     is to adjust the image recipe so that the headless machine doesn't install
>     all the graphic stuff (usually you'll have to take a look at how some
>     packagegroups get included and change that).
> 
> In this particular case I can use DISTRO_FEATURES in my recipe and nicely use 
> one image recipe to produce multiple images, this is however not possible with 
> e.g. kernel modues, as such variable does not exist.

DISTRO_FEATURES is rather inconvenient as it requires separate builds.

Why don't you just have multiple image recipes? I usually have something like

project-name-image (for released product)
project-name-image-dev (same, but with development options like a writable 
root and gdbserver)
project-name-production-test (...)

> 
>     Wifi and bluetooth can be compiled as kernel modules and loaded on demand.
> 
> Yes, this would work as well. Though some would argue that out of security 
> reasons it's better to reduce the attack surface and not even have kernel 
> modules to be loaded in the first place if they are not needed at all.

Safer even is to not have the modules on the filesystem at all, then the 
kernel cannot load them...

Normally the kernel only loads modules that it needs (systemd, udev, and even 
busybox' mdev feature on-demand module loading so you never have to forcibly 
"modprobe" anything)

Many images bluntly install "kernel-modules" which throws in everything that 
got built by the kernel recipe. Omit that and you can install kernel modules 
based on exact system requirements.