- No, it’s not a process
- User threads are not rooted at init.
Init is just the first process; it does not manage any proceses or threads. It does create some, using the kernel syscalls fork() and exec.
I think you have a muddy idea of what a process is. it doesn’t just mean a bit of executing code. Yeah, the kernel executes before init (and the boot loader before that even). But a ‘process’ has a specific definition of:
- Runs in user space
- Runs with a process ID
- Many interactions need to go through the kernel
- All resources need to come from kernel
- Needs to be scheduled by kernel
So, once the kernel initializes, it runs init, which then spawns whatever other processes its configuration says to.
As far as #2 goes, all the kernel stuff is, well, in the kernel. Think of the kernel as a large area of code. Again, not a process, but a large code blob. Parts of the kernel deal with memory management, parts of it with scheduling portions of itself (like drivers, etc.), and parts of it with scheduling processes.
The kernel doesn’t really behave like a process at all. It doesn’t get scheduled, it either runs on behalf of a process (so called process-context or user-context), or runs as a result of an interrupt or exception (so called interrupt-context).
That said, the Linux kernel spawns kernel threads to perform some tasks, or to avoid running something on interrupt context for too long (that is what the ksoftirqd thread does, avoiding excessive latencies that could lead e.g: to dropped audio,…).
You can see the kernel threads on the output of the
ps command. They are easily identified: their name is between brackets. Some of them run one instance per CPU, the CPU is identified with a number after a slash, so [ksoftirqd/0] is the instance of ksoftirqd on CPU 0.
There are concepts in micro-kernels where various parts of the kernel are indeed processes with the primary sentinel mostly just manages IPC.
Linux–for better or worse–is not a micro kernel system.
No, it is not… Kernel (and kernel extensions) are directly loaded into the memory. If there is unsafe code in kernel, nothing stands between it and big trouble.
That aside, kernel basically executes/switches between processes. Obviously something that actually runs processes won’t be a process itself.
(tl;dr 1. no 2. part of kernel / its extension)
ninjalj wrote: “The kernel doesn’t really behave like a process at all. It doesn’t get scheduled,”
Well, there is the idle process (basically pid 0, though it is not shown anywhere) which is scheduled and about always in a runnable state.
❖ Processes are managed by a shared chunk of OS code called the kernel
▪ The kernel is not a separate process, but rather runs as part of a user process
❖ Context switch passes control flow from one process to
another and is performed using kernel code