Spinning the wheel

% After dealing with all the tricky questions, <#2427#> start_kernel()<#2427#> initializes all the parts of the kernel, specifically: Finally, the kernel is ready to <#2431#> move_to_user_mode()<#2431#>, in order to fork the <#2432#> init<#2432#> process, whose code is in the same source file. Process number 0 then, the so-called idle task, keeps running in an infinite idle loop. The <#2433#> init<#2433#> process tries to execute <#2434#> /etc/init<#2434#>, or <#2435#> /bin/init<#2435#>, or <#2436#> /sbin/init<#2436#>. If none of them succeeds, code is provided to execute ``<#2437#> /bin/sh /etc/rc<#2437#>'' and fork a root shell on the first terminal. This code dates back to \ 0.01, when the OS was made by the kernel alone, and no <#2438#> login<#2438#> process was available.

After <#2439#> exec()<#2439#>ing the <#2440#> init<#2440#> program from one of the standard places (let's assume we have one of them), the kernel has no direct control on the program flow. Its role, from now on is to provide processes with system calls, as well as servicing asynchronous events (such as hardware interrupts). Multitasking has been setup, and it is now <#2441#> init<#2441#> who manages multiuser access by <#2442#> fork()<#2442#>ing system daemons and <#2443#> login<#2443#> processes. Being the kernel in charge of providing services, the tour will proceed by looking at those services (the ``system calls''), as well as by providing general ideas about the underlying data structures and code organization.