从init到shell

从init到shell
start_kernel()->rest_init()->kernel_thread()
从此之后
...
    schedule();
    cpu_idle();
cpu开始空转(如果没有进程要运行的话)，而kernel_thread()创建出了根内核进程init，init的内容如下

if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
        printk(KERN_WARNING "Warning: unable to open an initial console.\n");

    (void) sys_dup(0);
    (void) sys_dup(0);
    
    /*
     * We try each of these until one succeeds.
     *
     * The Bourne shell can be used instead of init if we are 
     * trying to recover a really broken machine.
     */

    if (execute_command)
        run_init_process(execute_command);

    run_init_process("/sbin/init");
    run_init_process("/etc/init");
    run_init_process("/bin/init");
    run_init_process("/bin/sh");

    panic("No init found.  Try passing init= option to kernel.");

当我们从命令行中传递过去init=xxx的字样的时候(不用initrd)，那么execute_command中的内容就是
xxx 了，经实验，除了
"noinitrd root=/dev/mtdblock2 init=/linuxrc console=ttySAC0"
下面的init也是可以的
init=/sbin/init 或者/bin/sh 或者init=/sbin/getty 115200 console
其实linuxrc是链接到/bin/busybox的，而busybox就是首先执行的/sbin/init(我猜的)，

注意sys_open((const char __user *) "/dev/console", O_RDWR, 0)这个句子，为什么呢？

那要从tty驱动谈起：

1。    其实每个tty设备(4,1)(4,2)(4,3)...(4,63)(4,64)...都想认领一个进程，作为与自己交互的对象，就是说，当我们往某个tty
    设备上写入数据时，或者希望从某个tty设备上得到数据时，tty设备(驱动)都希望把这些数据流交给某个进程去处理，否则tty没有存在的意义
    从tty驱动的角度来看，这个程序就是发起一次会话的那个进程。

2。    从这个发起对话的进程的角度来看，任何一个想使用tty驱动程序，来完成与用户交互的进程都希望能得到一个控制终端(键盘+vga或者串口)，
    以便能和用户互动。

所以open一个tty设备就要小心了，因为有些进程不想与用户交互(比如守护进程，他不希望给用户什么，也不希望从用户那里得到什么)。
扯回来，我们在init内核进程中，他是do_fork创建出来的第一个进程(或者叫内核线程?)，kernel_thread->do_fork()，他的pid是1。
/dev/console (5,1)是一个终端设备(控制台)，打开它有可能是本init内核线程拥有一个控制终端(控制台)，而init此时并不需要得到一个
控制台,那么此时的open就得保证打开/dev/console(5,1)时不会成为其控制进程(controlling process)。怎么保证一个进程在打开tty
设备文件时不会成为其控制进程呢？那得看tty_open()了

if (!noctty &&
        current->signal->leader &&
        !current->signal->tty &&
        tty->session == 0) {
            task_lock(current);
        current->signal->tty = tty;
        task_unlock(current);
        current->signal->tty_old_pgrp = 0;
        tty->session = current->signal->session;
        tty->pgrp = process_group(current);
    }

要想一个进程打开tty设备文件时不成为其控制进程只要满足下面的条件之一就可以了
1。open是指定O_NOCTTY。
2。本进程不是一个会话的首进程，就是说本进程不想开始一个对话，于用户交流。
3。本进程已经有了控制终端，就是说一个进程不能同时与两个tty设备交互
4。本tty设备(驱动)已经有一个进程认领了，就是说本tty设备已经与一个进程交互，开始和用户对话了。

initialize_tty_struct()将tty_struct结构的所有不关心的元素都设置成了0(memset())
所以tty_open的时候，如果是第一次打开某个tty设备， 那么tty->session 肯定为 0，表示还没有开始一个对话

那么此时的 sys_open((const char __user *) "/dev/console", O_RDWR, 0)会不会将自己
变成(5,1)设备的控制进程呢？ 答案是不会，这里的第2个条件被满足。

rest_init->kernel_thread->do_fork,而
do_fork->copy_process->copy_signal->sig->leader = 0;    /* session leadership doesn't inherit */
也就是说凡是do_fork函数创建的内核线程，他的leader初始值都是0，意义重大，表示他不想作为一个会话的的领导进程，
就是说他不想开始一次会话。那么到底是谁想开始会话，与用户交互呢？

run_init_process(execute_command)->execve->do_execve最终把linuxrc文件load到内存并运行。
linuxrc是到busybox的符号连接，而busybox执行init.c文件(有待证实，如果从命令行传递init=/bin/init，跟init=/linuxrc
效果是一样的)，加上do_execve()不改变进程pid，进程组id，等等，只要不出错返回，现在内核init线程已经消失，蜕变成了用户空间
的/bin/busybox程序。那么busybox进程会不会是对话首进程呢？

在好好看看这个execve()
execve(init_filename, argv_init, envp_init);
static char * argv_init[MAX_INIT_ARGS+2] = { "init", NULL, };
char * envp_init[MAX_INIT_ENVS+2] = { "HOME=/", "TERM=linux", NULL, };
上面的init_filename就是/linuxrc

他增加了两个环境变量"HOME=/", "TERM=linux"，并且传递给main()函数 的argv是"init"，
经过两个dup，此时的内核线程init已经有了标准输入，输出，错误输出了。从而
execve()也继承了这三个已经打开的文件，即fd 0，1，2。没有执行时关闭标志

这样就到了busybox的main()中：
到了这里，其实我们相当于在运行
#init 这样的shell命令，表示此时的main()函数的argc=1,agrv[0]="init"，

其实这跟
#busybox init 或者
#/bin/busybox busybox busybox init是一样的效果最终都会调用busybox里的init_main()

函数调用路径是
main()->run_applet_by_name()->...到具体的小程序中

现在应该到了
init_main()
时刻提醒自己，现在的串口控制台还没有认领对话进程呢。
到了这里
int init_main(int argc, char **argv)
此时的argc=1,argv[0]="init"

    if (argc > 1 && !strcmp(argv[1], "-q")) {
        return kill(1,SIGHUP);
    }


首先是对退出参数的检测，如果#init -q的话，肯定会执行成功的，不信你可以#echo $?

if (getpid() != 1 &&
        (!ENABLE_FEATURE_INITRD || !strstr(bb_applet_name, "linuxrc")))
    {
        bb_show_usage(); //这个usage什么也不做，只是设置出错码并退出
    }

这个逻辑的意思是：
1。如果本进程是linux的一号进程，就是经过蜕变的那个进程可以继续运行
2。如果不是一号进程，那么肯定是从shell中执行的init命令：这又分两种情况
    1。如果只是单纯的敲入#init或者#busybox init，那么不可以继续运行
    2。如果init的前面有linuxrc字样，恭喜你，init会继续为你服务
        例如你敲上#/linuxrc init，此时^c会使linux重新启动

    signal(SIGHUP, exec_signal);
    signal(SIGQUIT, exec_signal);
    signal(SIGUSR1, shutdown_signal);
    signal(SIGUSR2, shutdown_signal);
    signal(SIGINT, ctrlaltdel_signal);
    signal(SIGTERM, shutdown_signal);
    signal(SIGCONT, cont_handler);
    signal(SIGSTOP, stop_handler);
    signal(SIGTSTP, stop_handler);

安装信号处理函数，如果此时你按住^c，那么应该不会重启，因为tty驱动还没有开始对话呢，也就是说console现在没人认领呢。

    /* Turn off rebooting via CTL-ALT-DEL -- we get a
     * SIGINT on CAD so we can shut things down gracefully... */
    init_reboot(RB_DISABLE_CAD);

static void init_reboot(unsigned long magic)
{
    pid_t pid;
    /* We have to fork here, since the kernel calls do_exit(0) in
     * linux/kernel/sys.c, which can cause the machine to panic when
     * the init process is killed.... */
    if ((pid = fork()) == 0) {
        reboot(magic);
        _exit(0);
    }
    waitpid (pid, NULL, 0);
}

这里他通过系统调用sys_reboot()告诉linux不要把ctl+alt+del解释成重新启动，而是什么都不作。

    /* Figure out where the default console should be */
    console_init();

这个函数用于确定init使用的控制台类型，有两类(serial和vga+键盘)，我们的init在内核线程状态的时候就已经打开了三个
文件了，fd 0，1，2。(/dev/console)，经execve()，init到了busybox，他还继承着那三个文件描述符呢。现在是时候
测试下这个/dev/console到底是什么终端的时候了(肯定是串口控制台)，他测试/dev/console文件到底是什么控制台的方法是：

1。    首先确定控制台设备文件
    1。    如果linux传递过来了console CONSOLE这样的环境变量，那么，就认定，这两个变量里就应该
        是控制台设备文件了。
    2。    如果linux没有传递过来这样的参数(当然没有，除非你自己putenv())，那么用ioctl(0, TIOCGSERIAL, &sr)去测试
        /dev/console是不是串口控制台，如果ioctl返回0说明在串口核心层实现了这个ioctl，也就是说有串口tty驱动被安装，那么
        确定设备文件为/dev/tts/0
    3。    如果/dev/console不是串口控制台，那就测试ioctl(0, VT_GETSTATE, &vt)是否返回0，是，就说明/dev/console是
        虚拟控制台(vga+键盘)，确定设备文件为/dev/vc/0
    4。    不是以上两中控制台，那么是用默认设备文件/dev/console
    其实我的控制台设备文件这里被确定为/dev/tts/0
2。    确定了控制台设备文件还不够，如果打不开这个设备文件，也是徒劳。所以现在去打开它，
    如果打开成功，说明存在此设备文件(/dev/tts/0)，其实这个文件在初始化串口设备驱动的时候已经被创建了(/serial/s3c2410.c)
    最坏的情况是串口控制台不能使用，虚拟控制台也不能使用，那就把设备文件改回/dev/console，这中情况发生在你用并口控制台？
    如果是串口控制台，用putenv("TERM=vt102");将linux传递过来的TERM环境参数改成vt102，为以后作准备。
3。    最后关闭这个文件，到此，这个函数已经确定了一个可用的控制台设备文件了，即/dev/tts/0

注意这个函数里的打开文件操作，因为这个操作有可能开始一个对话，这里没有，因为。。。

继续init_main

/* Close whatever files are open, and reset the console. */
    close(0);
    close(1);
    close(2);

    if (device_open(console, O_RDWR | O_NOCTTY) == 0) {
        set_term();
        close(0);
    }

    chdir("/");
    setsid();

关闭从init那里继承过来的三个文件描述符，此时如果在打开一个文件的话，毫无疑问返回的fd应该是0，
device_open()打开某个文件，并返回他的文件fd，并且保证此文件不阻塞打开，因为init没时间等，也没必要等
然后调用set_term()设置此串口tty设备(/dev/tts/0)的驱动属性。这其实就确定使用串口的方法，注意
此函数只能从标准输入fd设置某个设备的驱动属性。
然后改变当前目录为根目录，并调用setsid()，这是一次伟大的历史转折点，因为一旦init进程调用了setsid()
就表示它要启动一次对话了，因为调用setsid()结果是该进程成为新的会话组长和新的进程组长，并与原来的登录会话和进程组脱离。
由于会话过程对控制终端的独占性，进程同时与控制终端脱离。
对于init进程，谈不上与控制终端脱离，因为他压根儿没有取得驱动控制终端哦！这就是每次open操作我所描述的。
其实这里有个问题，就是init能不能setsid()成功？答案当然是能。但是为什么呢？记得守护进程setsid()成功的秘诀是
父进程退出，在子进程中才能setsid()，意思是说，只有当一个进程不是组长进程的时候，才可以setsid()，问题是init是不是
进程组组长，当然不是，组长是0号进程，init的父进程也是0号进程，因为他是0号进程fork()过来的，所以敢肯定他不是组长哦。

在内核代码找了好久没找到，但是可以如下证明：

lzd@lzd-laptop:~$ ps -axj |head -10
 PPID   PID  PGID   SID TTY      TPGID STAT   UID   TIME COMMAND
    0     1     1     1 ?           -1 Ss       0   0:02 /sbin/init
    0     2     0     0 ?           -1 S<       0   0:00 [kthreadd]
    2     3     0     0 ?           -1 S<       0   0:00 [migration/0]
    2     4     0     0 ?           -1 S<       0   0:00 [ksoftirqd/0]
    2     5     0     0 ?           -1 S<       0   0:00 [watchdog/0]
    2     6     0     0 ?           -1 S<       0   0:00 [events/0]
...

看到了吧，init的父亲是0号内核线程，就是start_kernel()，之所以进程组id现在成了1，对话组id成了1，是因为setsid的结果。
还可以发现 kthreadd也是0号进程字进程，他的对话id(无意义)，组id都是0，说明这也是0号内核线程fork()出来的，只是没有setsid()，
呵呵，之后的进程都属于0号进程组，说明他们的祖宗是0号进程，但是父进程成了2，说明这些内核线程是2 fork出来的。当然这里的是x86的
情况，arm板子上跑的那个linux也应该相同的道理，只是busybox的ps是简化的，所以...

ok，回到init，他现在已经setsid()了哦！！！
此时如果他不小心open一个终端设备，并且没有加上O_NOCTTY标志，那么毫无疑问本进程会成为他的控制进程，那个tty设备也会认领本
进程为自己的对话进程。

    {
        const char * const *e;
        /* Make sure environs is set to something sane */
        for(e = environment; *e; e++)
            putenv((char *) *e);
    }

把预定义的环境变量递交给内核。跳过启动swapon的操作，没有硬盘交换有什么用吗？？？

    /* Check if we are supposed to be in single user mode */
    if (argc > 1 && (!strcmp(argv[1], "single") ||
                     !strcmp(argv[1], "-s") || !strcmp(argv[1], "1"))) {
        /* Start a shell on console */
        new_init_action(RESPAWN, bb_default_login_shell, "");
    } else {
        /* Not in single user mode -- see what inittab says */

        /* NOTE that if CONFIG_FEATURE_USE_INITTAB is NOT defined,
         * then parse_inittab() simply adds in some default
         * actions(i.e., runs INIT_SCRIPT and then starts a pair
         * of "askfirst" shells */
        parse_inittab();
    }

如果传递过来的命令行参数里有“single“ 或 ”-s“ 或 ”1“ 字样的参数，比如
"noinitrd root=/dev/mtdblock2 init=/linuxrc single console=ttySAC0"
那么init为你确定一个默认的登录shell。否则就认为你不是忘了密码，那么解析/etc/inittab文件的内容。
先看看单用户模式，init为我们作了什么。

/* Allowed init action types */
#define SYSINIT     0x001
#define RESPAWN     0x002
#define ASKFIRST    0x004
#define WAIT        0x008
#define ONCE        0x010
#define CTRLALTDEL  0x020
#define SHUTDOWN    0x040
#define RESTART     0x080

new_init_action(RESPAWN,"-/bin/sh","")

/* Set up a linked list of init_actions, to be read from inittab */
struct init_action {
    pid_t pid; //这个行为的进程号
    char command[INIT_BUFFS_SIZE]; //这个行为的命令
    char terminal[CONSOLE_BUFF_SIZE]; //使用的终端
    struct init_action *next; //下个行为
    int action; //行为的类型，上面8种之一
};

/* Static variables */
static struct init_action *init_action_list = NULL;

这里给以后需要的操作创建了一个单链表，新的脸表元素会追加到以init_action_list为链表头的最后。
如果没有指定最后的控制台参数，使用默认的console，就是前面确定的那个console设备(/dev/tts/0)
如果指定使用/dev/null作为控制台，并且是ASKFIRST的行为，那么不追加，当作不存在。
如果新加入的"行为"的命令和使用控制台与原来的某个行为一样，那么只覆盖原来的行为，也不追加。

parse_inittab();

很重要，如果没有配置CONFIG_FEATURE_USE_INITTAB，那么使用init默认的各种行为，
如果配置了CONFIG_FEATURE_USE_INITTAB，但是文件系统中找不到/etc/inittab，那么也使用默认
友善的就是找不到/etc/inittab，使用的是默认的各种行为，如果你把/etc/inittab_改成inittab，
那么会发现login程序，否则就直接给shell了。

    /* Make the command line just say "init"  -- thats all, nothing else */
    fixup_argv(argc, argv, "init");

到了这里，像他所说的，只是保证argv第一个字符串是 "init",其他的都清空(wipe)，使ps不会很凌乱(clutter)?
在下面的逻辑之前，先看看init默认的行为(就是不用inittab文件的情况)都在 init_action_list 链入了什么


CTRLALTDEL    :/sbin/reboot        :/dev/tts/0
SHUTDOWN    :/bin/umount -a -r    :/dev/tts/0
SHUTDOWN    :/sbin/swapoff -a    :/dev/tts/0
RESTART        :/sbin/init            :/dev/tts/0
ASKFIRST    :-/bin/sh            :/dev/tts/0
            :-/bin/sh            :/dev/vc/2
            :-/bin/sh            :/dev/vc/3
            :-/bin/sh            :/dev/vc/4
SYSINIT        :/etc/init.d/rcS    :/dev/tts/0

开始下面的逻辑分析：

/* Now run everything that needs to be run */

    /* First run the sysinit command */
    run_actions(SYSINIT);

    /* Next run anything that wants to block */
    run_actions(WAIT);

    /* Next run anything to be run only once */
    run_actions(ONCE);

#ifdef CONFIG_FEATURE_USE_INITTAB
    /* Redefine SIGHUP to reread /etc/inittab */
    signal(SIGHUP, reload_signal);
#else
    signal(SIGHUP, SIG_IGN);
#endif /* CONFIG_FEATURE_USE_INITTAB */

分析下run_actions()这个函数的逻辑。

/* Run all commands of a particular type */
像他解释的那样，此函数将所有的8种命令行为细分成三组：

1：SYSINIT | WAIT | “CTRLALTDEL | SHUTDOWN | RESTART”
2：ONCE
3：RESPAWN | ASKFIRST

对于第一组中的行为，run_actions()->waitfor()->run()
init(pid=1)在调用了run_actions()之后，将运行队列中的所有对应的行为。当运行的是1组中的行为时，run_actions()
(pid=1)期望能够给run的子进程收尸，而在run()中，落实到最终的exec()调用时，父进程仍然期待给子进程收尸，并且
会在退出之前还原控制终端为未用状态(steal away)。也就是说，组1的命令不会是一次对话的开始。最后pid=1的进程会从列表
中删除组1，2中的命令行为，而对于组三中的命令行为，则保留在队列中，但是对他们的处理是，如果这些命令在运行，那么
在调用run_actions()将不会执行。

这里的逻辑意义似乎是对于组1，2中的东东，init都视为系统进入一个可用环境之前，必须要运行的初始化环境过程，
而组3被认为是发起一次会话的过程。

当run的是ASKFIRST时，会打印
Please press Enter to activate this console. 
字样。可以发现init运行这些行为的顺序依次是

1。SYSINIT
2。WAIT
3。ONCE
4。解析“CTRLALTDEL | SHUTDOWN | RESTART”信号
5。进入无限循环。先RESPAWN，后ASKFIRST。

对于当找不到inittab文件，或者使用默认的配置的时候，只有1。SYSINIT被执行。然后进入了主循环

/* Now run the looping stuff for the rest of forever */
    while (1) {
        /* run the respawn stuff */
        run_actions(RESPAWN);

        /* run the askfirst stuff */
        run_actions(ASKFIRST);

        /* Don't consume all CPU time -- sleep a bit */
        sleep(1);

        /* Wait for a child process to exit */
        wpid = wait(NULL);
        while (wpid > 0) {
            /* Find out who died and clean up their corpse */
            for (a = init_action_list; a; a = a->next) {
                if (a->pid == wpid) {
                    /* Set the pid to 0 so that the process gets
                     * restarted by run_actions() */
                    a->pid = 0;
                    message(LOG, "Process '%s' (pid %d) exited.  "
                            "Scheduling it for restart.",
                            a->command, wpid);
                }
            }
            /* see if anyone else is waiting to be reaped */
            wpid = waitpid (-1, NULL, WNOHANG);
        }
    }
}

init的主要任务就是给他的子进程收尸了，而子进程可以是RESPAWN ASKFIRST组中的执行命令，也可以是init收养的孤儿进程
如果是RESPAWN ASKFIRST组中的东东，那么a->pid = 0将导致while的前两句从新执行。对于默认，当你exit退出本次对话
的时候，此init将不断给你一个shell。