init from the kernel side -- s243a's legacy bumbling.

[s243a]

These are some notes to me about the kernel side of the linux init process. Feel free to participate in the discussion.

This applies to modern kernels but out of ignorance or stubbornness, I'm looking at how they support legacy type "initial ram disks". In reality I'm just crashing straight into the code with little knowledge of c but I have some sources about how this init process is supposed to work to aid my swim.

Since I am reference the current source the discussion doesn't have to be strictly legacy but it is with curiosity about the legacy in which I plunge into the kernal source.

So I begin with an excerpt from an ibm article:

init/main.c:init
-- init/do_mounts.c:prepare_namespace 1.1
---- init/do_mounts_initrd.c:create_dev 1.1.1
---- init/do_mounts_initrd.c:initrd_load 1.1.2
------ init/do_mounts_rd.c:rd_load_image 1.1.1.1
-------- init/do_mounts_rd.c:identify_ramdisk_image 1.1.1.1.1
-------- init/do_mounts_rd.c:crd_load 1.1.1.1.2
---------- lib/inflate.c:gunzip 1.1.1.1.1.1
-init/do_mounts.c:mount_root 1.2
---- init/do_mounts.c:mount_block_root 1.2.1
------ init/do_mounts.c:do_mount_root 1.2.1.1
-------- fs/namespace.c:sys_mount 1.2.1.1.1
-- init/main.c:run_init_process 1.3
---- execve 1.3.1

https://www.ibm.com/developerworks/library/l-initrd/
which shows the call sequence of the kernal in the init process. The indentation denotes the function stack.

jamesbond tells me this IBM article is quite dated. But nonetheless it was published after Rob Landley excenlent article on the differences between ramfs, rootfs and initramfs, which I discovered on superuser.com. Also I was able to link most of the outlined startup init trace to the current source.

I wish I had more time to delve into this further tonight but it took me a while to make all the above links.

More to follow as I delve into it further.

------------------
Edit I added extra trace Items above in red.

Edit More from the IBM article

A call is made here to init/do_mounts.c:prepare_namespace(), which is used to prepare the namespace (mount the dev file system, RAID, or md, devices, and, finally, the initrd)

at the end of this function

[technosaurus]

The kernel code is actually pretty easy to read, check out kernel_init in https://git.kernel.org/pub/scm/linux/ke ... .c?h=v4.15

[s243a]

The kernel code is actually pretty easy to read, check out kernel_init in https://git.kernel.org/pub/scm/linux/ke ... .c?h=v4.15

It seems okay. Reasonably well commented. However, I get lost when they start referencing functions which aren't in the code. One place this seems to occur is with system calls. I have a feeling that some of these are implemented in assembly and then the related macros in the c headers are confusing to me.

sys_mount is one such system call that I couldn't find how it is implemented in the code.

[technosaurus]

Yeah, the codebase is admittedly bloated. I usually just Google the function and go to whatever free-electrons page comes up ... they show where each symbol is defined and where it is used.