1. In Linux, we always say the first process is init (pid==1). But why is not the kernel (startup) which setup the system and create the init process. Is kernel a process?
  2. We know all the user space threads are rooted at init process. Then what about scheduler and other kernel stuff, like memory management?

Basically, what confuses me is the structure of the kernel. If it is a process, is it a single process, or it consists of multiple processes?


Short answers:

  1. No, it's not a process
  2. 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.

  • 3
    I wonder if the OP knows enough to have his mind blown by micro kernels? I didn't include it my edit because I thought it would be distracting, at any rate. – new123456 Jul 11 '11 at 3:26
  • 5
    One way of thinking of the kernel is like a gigantic library, with entry points (the system calls) to ask it to do something on your behalf. Another, complementary view, is that it sits waiting for events to handle, be it a system call from the user or a hardware interruption (e.g., new network packet arrived). Some stuff takes time to handle, so the kernel just ships the work off to internal threads and returns to whoever called. – vonbrand Jan 16 '13 at 14:35

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.


Context Switching

❖ 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

Source: https://courses.cs.washington.edu/courses/cse351/19su/lectures/18/CSE351-L18-processes_19su.pdf, page 36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy