[CWS] multiple fixes around runtime compiled constants

[paulcacheux]

What does this PR do?

This PR contains fixes for both the global kernel headers downloading mechanism and CWS specific usage around runtime compiled constants.

Regarding kernel headers downloading, this PR:

• adds checks for other files than linux/types.h, namely linux/kconfig.h and opens the door to add more critical file dependencies in the future
• adds a verification that this critical files are present in the common path. This was missing from the "do we already have kernel headers in the standard paths" path leading to accepting incomplete headers
• relaxes the kernel header version check to only major and minor. This is important since headers in /lib/modules are not versioned with the full version

Regarding CWS specific code, this PR:

• enables kernel headers downloading for functional tests
• fixes an issue where a user could enable the runtime compiled constants even though the runtime compiler was disabled
• changes the runtime compiled constants fallback test filename so it is run earlier in the testsuite, resulting in a shorter feedback loop regarding this critical test

Motivation

Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

Reviewer's Checklist

• If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
• The appropriate team/.. label has been applied, if known.
• Use the major_change label if your change either has a major impact on the code base, is impacting multiple teams or is changing important well-established internals of the Agent. This label will be use during QA to make sure each team pay extra attention to the changed behavior. For any customer facing change use a releasenote.
• A release note has been added or the changelog/no-changelog label has been applied.
• Changed code has automated tests for its functionality.
• Adequate QA/testing plan information is provided if the qa/skip-qa label is not applied.
• If applicable, docs team has been notified or an issue has been opened on the documentation repo.
• If applicable, the need-change/operator and need-change/helm labels have been applied.
• If applicable, the config template has been updated.

[brycekahle]

Do you have something I can read regarding this? We are using the actual LINUX_VERSION_CODE constant from the version.h file, which should contain the sublevel.

[paulcacheux]

Yes this is a bit strange but on OpenSUSE 15:
uname -a = Linux opensuse15 5.3.18-59.37-default #1 SMP Mon Nov 22 12:29:04 UTC 2021 (d10168e) x86_64 x86_64 x86_64 GNU/Linux

>> cat /usr/src/linux-5.3.18-59.37-obj/x86_64/default/include/generated/uapi/linux/version.h
#define LINUX_VERSION_CODE 328466
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))

>> cat /usr/include/linux/version.h
#ifdef __KERNEL__
#error "======================================================="
#error "You should not include /usr/include/{linux,asm}/ header"
#error "files directly for the compilation of kernel modules."
#error ""
#error "glibc now uses kernel header files from a well-defined"
#error "working kernel version (as recommended by Linus Torvalds)"
#error "These files are glibc internal and may not match the"
#error "currently running kernel. They should only be"
#error "included via other system header files - user space"
#error "programs should not directly include <linux/*.h> or"
#error "<asm/*.h> as well."
#error ""
#error "Since Linux 2.6, the kernel module build process has been"
#error "updated such that users building modules should not typically"
#error "need to specify additional include directories at all."
#error ""
#error "To build kernel modules, ensure you have the build environment "
#error "available either via the kernel-devel and kernel-<flavor>-devel "
#error "packages or a properly configured kernel source tree."
#error ""
#error "Then, modules can be built using:"
#error "make -C <path> M=$PWD"
#error ""
#error "For the currently running kernel there will be a symbolic "
#error "link pointing to the build environment located at "
#error "/lib/modules/$(uname -r)/build for use as <path>."
#error ""
#error "If you are seeing this message, your environment is "
#error "not configured properly. "
#error ""
#error "Please adjust the Makefile accordingly."
#error "======================================================="
#else
#define LINUX_VERSION_CODE 328448
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
#endif

Where 328466 = 5.3.18 and 328448 = 5.3.0

[brycekahle]

OK. We originally didn't include /usr as a kernel header directory, but it was added for Fedora. @ISauve perhaps we need to reexamine that decision, and see if there is an alternative directory.

I'm a little uncomfortable only being specific to major.minor matching, because there is no guarantee that kernel struct member offsets won't change in a sublevel version change.

[paulcacheux]

Let's keep /usr and a full version check for now. If in the future we see some issues on OpenSUSE we'll find a better solution to this issue

[paulcacheux]

I say this because kconfig.h is not in /usr so it should be removed by the critical headers check