1

Let me explain how I think a kernel works:

  • When the computer is powered on, the kernel will start running (the BIOS will run the boot loader, and the boot loader will run the kernel I think).

  • Now the kernel will do some work (for example: initialize the Interrupt Descriptor Table, create the necessary processes for the user to be able to interact with the OS, etc.)

  • Once the kernel has finished doing what it must do (when the OS has become "fully loaded" for the user to start interacting with it), the kernel will stop running "on its own".

  • Now the kernel would still run but not "on its own", but rather in response to interrupts (for example: system calls, hardware timer interval expires, mouse moved, keyboard pressed, etc.), so when we now say that the kernel is running, we only mean that the interrupt handlers are being executed.

Am I correct in my understanding, or is it that even after the OS is "fully loaded", the kernel will continue to run just like any other process?

cadaniluk
  • 15,027
  • 2
  • 39
  • 67
user4582812
  • 591
  • 1
  • 4
  • 16

2 Answers2

3

Neither the above are actually entirely correct:

  • True: The kernel is somewhat similar to a shared library. But there are difference. The kernel actually IS a program, with its own arguments (passed from the boot loader), though not a process in the traditional sense. Said program is responsible for initializing a privileged memory and execution space (Intel: Ring 0, ARM: SVC or EL1), wherein it has full access to hardware and can initialize subsystems, including memory management (through which it creates the isolated virtual memory containers we call "processes"), scheduling (for threads, which run inside processes) filesystems, and more.

BUT:

The kernel spawns quite a few threads of its own in its memory space (which you can easily see in Linux, for example, using ps -ef and looking for the PPID of 2, or ps aux looking for RSS/VSIZE of 0), and in newer version of ps, [ ] markers. Darwin (MacOS/iOS) cannot show kernel threads with built in tools unless a specialized sys call (presently, #491, stack_snapshot_with_config) is used.

ONE of the kernel threads (exactly which , depends on OS) , "germinates" and becomes the user mode PID 1 - init (now "systemd" on newer Linux systemd), or launchd (Darwin). This iS NOT some inexpensive infinite loop. It has enough on its plate, adopting orphan processes (reaping them and preventing zombies), starting up tasks, and generally housekeeping. PID 1 itself blocks most of the time, and is NOT to be confused with idle tasks (which are , in fact kernel threads). PID 1 is also immortal (can't kill with -9) and should it die hideously (by some exception), the kernel usually panics.

Explanation #2 (334403) is more on the mark, but kernel threads keep on executing in the background. e.g. Linux kswapd which may do swapping in response to certain page faults. Or scheduled flushing of page/buffer (Darwin:unified) caches. That said, other transitions to kernel mode are usually indeed on system call (voluntary), or interrupt/exception (non-voluntary). That is, unless one of the kernel threads wakes up and needs to do something.

miken32
  • 42,008
  • 16
  • 111
  • 154
Technologeeks
  • 7,674
  • 25
  • 36
0

Your description is way off the mark.

The kernel is not a process. You are describing the bootstrap loading process in your first two steps. The boot process sets up the kernel but is not the kernel. Once the operating system is loaded, the bootstrap process effectively goes away.

In most systems there is no kernel process. Once the boot is finished, the kernel is only invoked through exceptions or interrupts that get dispatched to handlers (set up by the boot process). These exception and interrupt handlers run in the context of the process that caused the interrupt or happened to be running when the interrupt occurred.

HoldOffHunger
  • 18,769
  • 10
  • 104
  • 133
user3344003
  • 20,574
  • 3
  • 26
  • 62
  • My first step is describing the bootstrap loading process, but how does my second step is also describing the the bootstrap loading process? I mean, does the bootstrap loading process initializes the Interrupt Descriptor Table, and create the necessary processes? – user4582812 May 06 '17 at 23:22
  • The bootstrap process sets up the IDT. The only process strictly necessary after that (although this varies among systems) is a NULL process to execute when nothing else is available. – user3344003 May 07 '17 at 01:02
  • You mean the kernel does not set up the IDT? – user4582812 May 07 '17 at 01:05
  • No, the kernel cannot do anything without an IDT. In fact, the standard PeeCee bios has an IDT already loaded to start the boot process. That IDT is overridden by most operating systems. – user3344003 May 07 '17 at 01:13
  • So you mean that the IDT is initialized twice, one time by the bootstrap process and a second time by the kernel? – user4582812 May 07 '17 at 01:15
  • On the PeeCee the IDT is already in ROM. The boot process usually creates a new IDT. – user3344003 May 07 '17 at 01:16
  • This link says that the kernel initializes the IDT: https://0xax.gitbooks.io/linux-insides/content/Initialization/linux-initialization-2.html – user4582812 May 07 '17 at 01:28
  • I don't see that in the text. It's describing booting. – user3344003 May 07 '17 at 01:49
  • It's in the **Fill and load IDT** section (and the entire chapter is called **Initialization**). – user4582812 May 07 '17 at 01:52
  • You're dealing with the loader here. I guess part of the problem you have is that the loader itself is a mini operating system. – user3344003 May 07 '17 at 02:25
  • I have re-read your answer, and this is my understanding of it: You mean that from the time the computer is powered on to the time that the OS is "fully loaded" (i.e. when the user can start interacting with the OS), the kernel does not run, and what runs is some other "program" that set up the interrupt handlers among other things, and the only time that the kernel runs is when the interrupt handlers are being executed, did I understood you correctly? – user4582812 May 07 '17 at 04:17
  • Almost, the only time the kernel runs is when EXCEPTION and interrupt handlers are invoked. – user3344003 May 07 '17 at 14:28
  • In that case I have to disagree with you, because all the tutorials that I have read says that it is the kernel that is executed by the boot loader, and it is the kernel that does the necessary work to prepare the OS to be usable by the user (for example: initializing the IDT, etc.). This is another link that confirms what I just said: http://glennastory.net/boot/linux.html. Can you tell me where have you read that the kernel only runs when an exception and interrupt handler is invoked? – user4582812 May 07 '17 at 14:48
  • "These exception and interrupt handlers run in the context of the process that caused the interrupt [...]" Not necessarily. Linux interrupt do not run in the context of a process. That is a conscious design decision and is the main reason why ISRs cannot be scheduled. And since the question is tagged "linux," it's even wrong. – cadaniluk May 07 '17 at 15:44
  • "Can you tell me where have you read that the kernel only runs when an exception and interrupt handler is invoked?" THAT IS WHAT A KERNEL IS. You apparently have a grave misconception about the structure of most operating systems. As to the second comment: Linux strips down the context after an interrupt. From the CPU's POV there is always a process and that process is the one that was running when the interrupt occurred. – user3344003 May 07 '17 at 15:58
  • @user3344003 *"THAT IS WHAT A KERNEL IS. You apparently have a grave misconception about the structure of most operating systems"* Now I know where the misunderstanding comes from, you assumed that I am asking about how a kernel works in general, but in fact, my question is about the **Linux** kernel. But if you think that the Linux kernel also works the way to describe, please tell me where have you read that. – user4582812 May 08 '17 at 01:28