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).