2 weeks Ago
w the filesystem handles the inodes when we save a file. This boundary is called user space, which is where we write applications, libraries, and tools. But there's another world, kernel space, where the operating system's kernel resides and is responsible for managing system resources such as memory, CPU, and I/O devices.
We usually don't need to go below the socket or file descriptor level, but sometimes we do. Suppose you want to analyze an application to see how many resources it consumes. If you analyze the application from user space, you will not only miss out on a lot of useful details but also consume considerable resources just for the analysis itself, because every layer above the CPU or memory introduces some overhead.
To Go Deeper Suppose you want to delve deeper into the stack and somehow inject custom code into the kernel to analyze an application, trace system calls, or monitor network packets. What would you do? Traditionally, you have two options. Option 1: Edit Kernel Source Code If you want to change the Linux kernel source code and then send the same kernel to your customer's machines, you need to convince the Linux kernel community that the change is necessary.
Then, you will have to wait years for the new kernel version to be adopted by Linux distributions. For most cases, this is not a practical method and is somewhat impractical. Just for analyzing an application or monitoring network packets.
Option 2: Write a Kernel Module You can write a kernel module, which is a piece of code that can be loaded into the kernel and executed. This is a more practical approach, but it also comes with its own risks and drawbacks. First, you need to write a kernel module, which is not an easy task.
Then, you need to maintain it regularly because the kernel is a living thing that changes over time. If you do not maintain the kernel module, it will become obsolete and won't work with new kernel versions. Secondly, you risk breaking the Linux.
...
