0

I'm reading about the Linux kernel loading process (just to understand the whole sequence) and I have several doubts specially about the control transition between:

  1. The boot-loader and the kernel
  2. The kernel and the init process

For example, in the wikipedia I found the following:

The kernel as loaded is typically an image file, compressed into either zImage or bzImage formats with zlib. A routine at the head of it does a minimal amount of hardware setup, decompresses the image fully into high memory, and takes note of any RAM disk if configured.[3] It then executes kernel startup via ./arch/i386/boot/head and the startup_32 ()

Here I have several questions:

  1. What this routine stands for?
  2. In which part of the memory is loaded?
  3. Does it already include code to decompress the zImage or this code is loaded separately in another memory location?

I Continue reading on the same page and I found the following:

... start_kernel executes a wide range of initialization functions. It sets up interrupt handling (IRQs), further configures memory, starts the Init process (the first user-space process), ...

I know that the init is the first user-space process created. The answer to the following question:

How the init process is started in linux kernel?

states that the kernel uses a do_execve() call. However, the semantic for the normal execv system call is to override the calling process (the kernel in this case?) bss, data, text and stack segments with the ones from the new process and it doesn't return.

Why in this case it does return? (otherwise, if it doesn't return the kernel wont continue it's starting process)

Thanks in advance,

Community
  • 1
  • 1
rkachach
  • 16,517
  • 6
  • 42
  • 66
  • Related http://linuxseekernel.blogspot.ie/2015/08/kernel-entry-from-u-boot-mips.html – Jeyaram Sep 29 '15 at 15:34
  • shortly, do_execve "rewriting" dealth with mm things (userspace part). Because your do_execve starts from kernel thread called "kernel_init" it's old mm is entirely empty (cuz it is a kernel thread). So this is what your execve rewrites (i.e. nothing). Actually it doesn't return ... but it doesn't return to kernel_init thread, the rest of kernel is working fine – Alex Hoppus Sep 29 '15 at 15:58
  • @AlexHoppus, it's not clear to me from your answer. If it doesn't return how the rest of the kernel continue executing the startup process. Os this just the last point of the startup and from now on the init process will take the control and continue the startup? – rkachach Sep 30 '15 at 07:00
  • @redobot your problem is that you interpret linux kernel as ordinary process. In fact the "userspace process" is what linux kernel makes available to exist. As per "returning question" i think you could reread my answer again. – Alex Hoppus Sep 30 '15 at 07:48
  • @AlexHoppus I know that the kernel is not a process. But from the description I put above it seems that during the startup process it's treated as such. I re-read your answer and what I understand is: do_execve() create a new process and doesn't return (which is good). In parallel, kernel_init thread will continue executing. Is this correct? thanks. – rkachach Sep 30 '15 at 07:55
  • @redobot have you read from my answer that do_execve rewrites user space part of VA, or you skipped it? In parallel - kernel_init thread wouldn't proceed, because it will be an init process, but anything else in kernel will be alive including startup code flow, which will continue initialization. – Alex Hoppus Sep 30 '15 at 08:05
  • Yes I read it, and I understood this part. What I don't understand is "startup code flow, which will continue initialization". In which context does this code will continue executing? which [kernel]thread will continue executing this code? – rkachach Sep 30 '15 at 09:03
  • Well answered there: https://lwn.net/Articles/656286/ and https://lwn.net/Articles/657939/ – Alexandre Belloni Sep 30 '15 at 15:40
  • @AlexandreBelloni Thanks for the links, I'll read them. – rkachach Sep 30 '15 at 18:37

0 Answers0