sunnysideup wrote:
I've been doing a bit of operating systems development, and want to start looking at the linux kernel source code for inspiration and ideas. While doing OsDev, I realized that the kernel is only called during syscalls/interrupts, and thus I can view the kernel as a set of functions that may or may not be called. However, I want to know how linux handles the startup (grub loads the kernel and passes control to it), how the kernel is initialized and how it switches to user mode / what is the first process it executes. I kind of want to know the 'main()' function of the kernel before it takes the backstage and simply acts as a set of functions to be called by user mode. Is this a good way to start reading the linux source code?
High level overview: The code in arch/xxx/boot contains the decompressor. Linux' main image is always compressed and has to be decompressed before it can be started. Sort of like UPX handles it. Decompressor decompresses image, then jumps to its startup code.The code that runs then is somewhere in the relevant arch directory. Where exactly depends on the arch. For x86, the code is in arch/x86/kernel/head*.S. That code will perform arch-specific initialization, and usually initialize the memblocks, too. When the normal kernel environment has been created (for X86: Page tables are initialized as they should be, GS points to a CPU structure), the function kernel_start() is called. That function will initialize the arch-independent blocks in the kernel, initialize tasking, set itself up as the idle task, and then create the init task, before hanging itself into a halting loop. The init task will wait for kernel initialization to be completed, then initialize rootfs and do all that good stuff to locate the actual root disk. Then run /sbin/init from there. Then userspace takes over.
Whether this is a good way to read the Linux code depends on what you want to get out of it. If your goal is to understand Linux startup, then yeah, sure. If you want to understand a specific aspect of the kernel, maybe read about that other aspect directly.