Kernel Logs – Difference Between /proc/kmsg and /dev/kmsg

The reason why we need the thread_info is due to the fact that we are allocating the memory for task_struct using the Slab Allocator. Now you may ask what is the relation between these?

To understand that you need to understand how Slab Allocator works.

Without the Slab Allocator , the kernel developers could allocate memory for task_struct in the kernel stack for the particular process so that it can be accessed easily. Now with the advent of Slab Allocator , the memory is allocated to the task_struct as determined by the Slab Allocator. So with the Slab Allocator you have task_struct stored somewhere else and not in the kernel stack of the particular process. Now the Kernel developers introduced thread_info and placed a pointer in it to the place where the task_struct resides. And that is why we have to live with thread_info.

You can read about Slab Allocator in Robert Love's book Linux Kernel Development.

In the case of Linux, a task (kernel internal idea of a thread; threads can share resources, like memory and open files; some run only inside the kernel) can run in userland, or (it's thread of execution) can transfer into the kernel (and back) to execute a system call. A user thread can be highjacked temporarily to execute an interrupt (but that isn't really that thread running).

That a process is a "system process" or a regular user process is completely irrelevant in Unix, they are handled just the same. In Linux case, some tasks run in-kernel to handle miscellaneous jobs. They are kernel jobs, not "system processes" however.

One big caveat: Text books on complex software products (compilers and operating systems are particularly egregious examples) tend to explain simplistic algorithms (often ones that haven't been used in earnest for half a century), because real world machines and user requirements are much too complex to be handled in some way that can be described in a structured, simple way. Much of a compiler is ad-hoc tweaks (particularly in the area of code optimization, the transformations are mostly the subset of possibilities that show up in practical use). In the case of Linux, most of the code is device drivers (mentioned in passing as device-dependent in operating system texts), and of this code a hefty slice is handling misbehaving devices, which do not comply to their own specifications, or which behave differently between versions of "the same device". Often what is explained in minute detail is just the segment of the job that can be reduced to some nice theory, leaving the messy, irregular part (almost) completely out. For instance, Cris Fraser and David Hanson in their book describing the LCC compiler state that typical compiler texts contain mostly explanations on lexical analysis and parsing, and very little on code generation. Those tasks are some 5% of the code of their (engineered to be simple!) compiler, and had negligible error rate. The complex part of the compiler is just not covered in standard texts.