One of the important aspects a beginner who is into Linux Kernel space systems software development has to understand is that unlike user-space C/C++ programming, where you can freely include any library APIs via respective #include files (which are dynamically linked during run-time via those /lib .so files), in the case of Kernel space programming, these library APIs are written within the Kernel source itself.
What are those library APIs:
These are the fundamental APIs which we commonly use, such as memcpy(), memcmp(), strlen(), strcpy(), strcpy() and so on. Unlike user-space in which these APIs are cross-compiled as a part of tool-chain for that respective CPU platform, in the case of Kernel space, you find various variants of the same done for each and every CPU platform (such as ARM, x86, MIPS, etc). You can find the source code of the same usually in the /arch folder of the Linux kernel source. And each implementation is highly optimized for that specific CPU platform. Sometimes you can often find even in-line assembly in combination with the typical native kernel C source code.
The primary reason for such an approach in Kernel source is that all the code i.e libraries as well other kernel dependent (CPU platform independent) code is all packed in a self-sustained source repository. Because in the case of kernel, we cannot expect to have other external third-party run-time dependency files like we get in user-space, hence it is important to understand the same as you start your journey towards kernel space programming.
Refer Phoronix News Article – Whoops: Linux’s strcmp() For The m68k Has Always Been Broken ↗
So here is an interesting news article about a specific API such as in this case strcmp() written for native m68k (Motorola 68000) has always been broken and only now uncovered at the end of 2022.
So here is my detailed Youtube video episode on the same with live demo, walk-through and examples.