%
After dealing with all the tricky questions, <#2427#> start_kernel()<#2427#>
initializes all the parts of the kernel, specifically:
- Sets the memory bounds and calls <#2429#> paging_init()<#2429#>.
- Initializes the traps, IRQ channels and scheduling.
- Parses the command line.
- If requested to, allocates a profiling buffer.
- Initializes all the device drivers and disk buffering,
as well as other minor parts.
- Calibrates the delay loop (computes the ``BogoMips'' number).
- Checks if interrupt 16 works with the coprocessor.
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.