Consider using config fragments for kernel

[egernst]

Today we maintain a full defconfig per architecture, which makes it difficult to identify what is required for Kata at a minimum, versus what is pulled in as a default during the build process, versus what is a nice have for device support. Having a minimally configured kernel is very important from a footprint and security perspective. It'll be hard if we aren't clear/explicit.

Similarly, for new architectures are developers coming to Kata, it can be difficult to understand what options are needed to bootstrap a Kata-able kernel (example: yocto devs bringing up Kata).

Based on this, I think we should consider reworking how the kernel configuration is maintained for Kata project.

Ideally we would use a hierarchy of fragments, such as:

-required features for Kata
-base device enabling (ie, baseline of NICs, other hardware)
-architecture enabling (per architecture)

In the build process we'd be able to start with no-config or defconfig, and then add the appropriate fragments as needed (making use of merge_config.sh).

[egernst]

/cc @jon @jodh-intel @jcvenegas @bergwolf @sameo -- Feedback?

[grahamwhaley]

If we can make it work, then yes, I think that would be OK. Notes though:

• I don't necessarily like the idea of starting with a defconfig, and prefer a noconfig or tinyconfig (on the grounds of kernel size) - but I'm not sure if that is feasible for all architectures
• tbh, I don't think there are that many architectures that support VMs, and we already probably have the majority of the ones that matter - so, the point might be moot, or soon would be with the addition of one or two more architectures?

But, it would be nice to have a clean definitive list of CONFIGs we need, and why (and if some are optional and what they enable etc.)

[jodh-intel]

I think this is basically a duplicate of what I said on #8 (comment) ?

Related:

• Should we provide multiple guest kernel config files? #55
• create script to validate kernel options across architectures #56
• Consider requiring all kernel configs to provide /proc/config.gz #222
• Is there any value in introducing dynamically loadable kernel modules? #223

[egernst]

@jodh-intel agreed, and this has indeed been an open and oft-discussed. config_merge.sh is a standard part of linux build process, though, which I think would be beneficial.