The thread created by start_kernel forks out bdflush (whose code appears in fs/buffer.c) and kswapd (defined in mm/vmscan.c), which are therefore assigned process ids 2 and 3. The init thread (pid 1) then performs some further initialization that couldn’t be accomplished before; that is, it runs functions related to SMP and, if needed, the initrd booting technique, in the form of another kernel thread. After initrd is over, the init thread activates the ``pseudo-root'' of the UMSDOS filesystem.

The real role of init, after it’s done with initialization, is going to user space and executing a program (thus becoming a process). The three stdio channels are thus connected to the first virtual console, and the kernel tries to execute init from /etc. If that fails, it looks in /bin and then /sbin (where init lives in any recent distribution). If init fails to run from any of the three directories, the process tries to execute /etc/rc, and if that also fails, it loops, executing /bin/sh. In most cases, the function succeeds in running init; the other options are there to allow system recovery in case init can’t be executed.

If the kernel command line specifies a command to execute, using the init= some_program directive, process 1 executes the specified command instead of calling init.

Whatever the system setup, the init process ends up executing in user space, and any further kernel operation is in response to system calls coming from user programs.