进程是怎么描述的？这是一个提纲挈领性的东西，它可以把内存管理，文件系统，信号，进程间通信等等全都串联起来

进程的描述在操作系统原理里面被抽象为进程控制块PCB：Process Control Block，又称进程描述符，是操作系统用于管理控制进程的一个专门的数据结构，记录进程的各种属性，描述进程的动态变化过程，而PCB是系统感知进程存在的唯一标志

为了管理进程，内核必须对每个进程进行清晰的描述，进程描述符（task_struct）提供了内核所需了解的进程信息

1. struct task_struct数据结构很庞大

1235struct task_struct {

1664};

一共有429行代码。将进程描述符进行抽象，用一张图来描述task_struct的结构关系

The Linux process descriptor

2. Linux进程的状态与操作系统原理中描述的进程状态似乎有所不同，比如就绪状态和运行状态都是TASK_RUNNING，为什么呢？

Linux状态转换图

a. 我们调用fork创建好一个新进程的时候，它的状态是TASK_RUNNING(就绪，但是没有在运行)，当调度器选择我们新fork的这个进程的时候，它就切换到TASK_RUNNING(正在运行)

当进程是TASK_RUNNING这种状态的时候，也就是说它是可运行的，但它有没有在运行呢？这个取决于它有没有获得CPU的控制权，也就是说这个进程有没有在CPU上实际地执行，如果在CPU上实际地执行，那就是“正在运行”，如果被调度出去了，在等待，那就是“就绪，但是没有在运行”，这是和操作系统原理中描述的进程状态不同的地方

b. 一个正在运行的进程调用了do_exit()终止执行，就会进入EXIT_ZOMBIE(进程被终止)，随后系统会把僵尸进程处理掉

c. 一个正在运行的进程在等待特定的事件或者是资源的时候，就会进入阻塞态。而如果事件发生或资源可用，进程被唤醒并进入就绪态

看Linux内核描述的进程状态

203#define TASK_RUNNING		0
204#define TASK_INTERRUPTIBLE	1
205#define TASK_UNINTERRUPTIBLE	2

210#define EXIT_ZOMBIE		32

3. 进程的标识符pid

在进程描述符中，有个pid和tgid，用来标识进程

1330	pid_t pid;
1331	pid_t tgid;

4. 所有进程链表struct list_head tasks

为了对给定类型的进程（比如所有在可运行状态下的进程）进行有效的搜索，内核维护了几个进程链表

1295	struct list_head tasks;

把所有的进程通过双向循环链表链接起来

The process list

内核的双向循环链表的操作

Doubly linked lists built with list_head data structures

5. 程序创建的进程具有父子关系，在编程时往往需要引用这样的父子关系。进程描述符中有几个域用来表示这样的关系

Parenthood relationships among five processes

6. Linux为每个进程分配一个8KB大小的内存区域，用于存放该进程两个不同的数据结构：Thread_info和进程的内核堆栈

查看  /linux-3.18.6/include/linux/sched.h#2241

2241union thread_union {
2242	struct thread_info thread_info;
2243	unsigned long stack[THREAD_SIZE/sizeof(long)];
2244};

内核堆栈是由Thread_info和堆栈合在一起的union

7. struct thread_struct thread; //CPU-specific state of this task

当前任务CPU相关的状态(sp、ip)，它在进程上下文切换的时候起到关键性的作用

468struct thread_struct {

472	unsigned long		sp;

482#ifdef CONFIG_X86_32
483	unsigned long		ip;
484#endif

进程描述符task_struct数据结构

1235struct task_struct {	/* 进程描述符 */
1236	volatile long state;	/* 运行状态  -1 unrunnable, 0 runnable, >0 stopped */
1237	void *stack;		/* 进程的内核堆栈 */

1239	unsigned int flags;	/* 每个进程的标识符  per process flags, defined below */

1242#ifdef CONFIG_SMP		/* 条件编译，多处理的时候用到 */

1251	int on_rq;		/* 运行队列，run queue，和进程调度相关 */

1295	struct list_head tasks;		/* 进程的（双向循环）链表，把当前所有的进程链起来 */

1301	struct mm_struct *mm, *active_mm;	/* 进程的地址空间，内存管理有关（CS、DS） */
	/* 把具体复杂的东西忽略掉，就只认为：每个进程有自己独立的进程地址空间，32位x86体系结构的话，有4G的内存地址空间 */

1330	pid_t pid;		/* 进程的pid */

	/* 进程的父子关系 */
1342	struct task_struct __rcu *real_parent; /* real parent process */
1343	struct task_struct __rcu *parent; /* recipient of SIGCHLD, wait4() reports */

1347	struct list_head children;	/* list of my children */
1348	struct list_head sibling;	/* linkage in my parent's children list */
1349	struct task_struct *group_leader;	/* threadgroup leader */

1356	struct list_head ptraced;		/* 做调试用 */
1357	struct list_head ptrace_entry;

1360	struct pid_link pids[PIDTYPE_MAX];	/* pid的hash表，为了查找方便 */
1361	struct list_head thread_group;
1362	struct list_head thread_node;

1368	cputime_t utime, stime, utimescaled, stimescaled;	/* 和时间相关的代码 */
1369	cputime_t gtime;

1383	u64 start_time;		/* monotonic time in nsec */		/* 和时间相关的代码 */
1384	u64 real_start_time;	/* boot based time in nsec */

1411/* CPU-specific state of this task */
1412	struct thread_struct thread;		/* 当前任务和CPU相关的 */
1413/* filesystem information */
1414	struct fs_struct *fs;			/* 和文件系统相关的 */
1415/* open file information */
1416	struct files_struct *files;		/* 打开的文件描述符列表 */

1419/* signal handlers */
1420	struct signal_struct *signal;		/* 和信号处理相关的 */

1451#ifdef CONFIG_RT_MUTEXES			/* 条件编译和互斥锁MUTEXE */

1463#ifdef CONFIG_TRACE_IRQFLAGS		/* 和调试相关的 */

1598	struct pipe_inode_info *splice_pipe;		/* 管道 */

大致了解了进程描述符里的数据结构，进程描述符里面一些关键的部分是需要了解的：

    -- 进程的状态
    -- 内核堆栈
    -- 记录CPU（sp、ip）上下文的thread_struct
    -- 文件系统
    -- 信号
    -- 内存
    -- 进程空间

每个部分都可以延伸出去，在进程描述符里面有相应的指针，指向了每个部分的内容，如果要研究某个部分的内容的话，可以延伸出去。进程描述符是整个系统管理一个提纲挈领性的东西

在了解了进程描述符之后，则需要了解整个系统的工作机制。基于对进程描述符有了一个基础性的了解，进而深度剖析进程是怎么创建的？进程之间怎么调度和切换？整个系统的工作机制就能从总体上相对比较准确的把握

进程的创建概览及fork一个进程的用户态代码

进程的创建再回顾

start_kernel()的最后rest_init()里面创建了两个内核线程，一个是kernel_init（1号进程是所有用户态进程的祖先），一个是kthreadd（2号进程是所有内核线程的祖先），创建过程和我们在shell命令行启动一个进程的创建过程在本质上是一样的，都要从当前进程复制一份进程描述符

在系统启动的时候，0号进程是我们手工写进去的，进程描述符的数据结构都是硬编码。而1号进程的创建，是复制了一份0号进程的PCB，根据1号进程的需要把它的PCB给修改了，然后再加载一个可执行程序

进程是怎么创建起来的？根据前面的分析已经有了一个框架，复制一份创建出子进程，对子进程做一些修改，在进程调度的时候启动子进程，但子进程是从哪里开始执行的？这个对理解整个系统非常关键

通过一小段代码看怎样创建一个子进程

fork一个子进程的代码

fork系统调用在父进程和子进程各返回一次

通过这个小程序，fork在用户态创建一个子进程

此时创建进程看起来就好像是创建一个系统调用fork，但事实上比传统的系统调用还要复杂

系统调用再回顾

系统调用再回顾

用户态int 0x80（中断指令），把用户堆栈、EFLAGS、cs、eip压栈，而由于是陷入进入内核的，所以机器自动保存与转换堆栈。也就是从用户态堆栈转换到内核态堆栈，然后把CPU最关键的现场（eip、esp、EFLAGS）保存到内核堆栈里面，都是由CPU自动帮我们做的

int 0x80下一条指令就是跳转到汇编代码system_call，把eax压栈，然后SAVE_ALL，系统调用传递参数都在里面完成

系统调用处理完成之后，RESTORE_ALL，iret返回到用户态，itret和int 0x80的效果是对应的

fork系统调用

从父进程的角度来看，fork的执行过程如上图所示。fork系统调用，保护现场，找到系统调用表sys_call_table，在表里面记录了一个系统调用内核处理函数sys_fork，sys_fork返回到系统调用总控程序entry_32.s汇编代码，然后恢复现场就返回了

但问题是，fork之后，在服务程序里面又创建了一个子进程。父进程返回之后，父进程系统调用处理完返回和传统的处理过程没有区别，但是子进程copy了父进程所有的进程信息，包括内核堆栈，进程描述符等等所有的信息，然后做适当的修改，而修改之后，子进程作为一个独立的进程，它也会被调度执行，当子进程获得CPU的时候，也就是子进程开始执行的时候

Q：fork出的子进程是从哪里开始执行呢？

如果从用户态空间来看的话，是fork的下一条语句。但是，fork在子进程中也是有返回值的，返回值（pid）是0，也就是说，子进程在内核里开始执行，那么它在内核处理程序里什么地方开始执行的呢？

也就是一个新创建的子进程，它是从哪一行代码开始执行的？

理解进程创建进程过程复杂代码的方法

我们给了“fork创建一个子进程”一个框，这个框就是系统调用，但是这个系统调用和传统的系统调用在总的处理过程上大致上是一致的，但在创建一个进程的过程中，我们需要给它的业务过程建立一个框架

理解复杂事物要预设一个大致的框架

想象出它应该会怎样创建出一个进程，然后根据应该会怎样创建出一个进程来代码中找出证据，校正我们的设想

前面了解到，创建新进程是通过复制当前进程来实现的。因此，设想创建新进程的过程中需要做哪些事

1. 应该有一个地方复制父进程PCB，应该有很多地方修改PCB，使新进程拥有独立的特性
2. 应该有一个地方给新进程分配一个新的内核堆栈，因为新进程也是从fork返回到用户态的，内核堆栈一部分要从父进程拷贝过来，要不然内核堆栈没能返回
3. 要修改复制过来的进程数据，比如pid、进程链表等等，根据拷贝的内核堆栈，设定eip、esp的位置

系统调用内核处理函数sys_fork、sys_clone、sys_vfork

fork、vfork和clone三个系统调用都可以创建一个新进程，而且都是通过调用do_fork来实现进程的创建

查看  /linux-3.18.6/kernel/fork.c

1702#ifdef __ARCH_WANT_SYS_FORK
1703SYSCALL_DEFINE0(fork)
1704{
1705#ifdef CONFIG_MMU
1706	return do_fork(SIGCHLD, 0, 0, NULL, NULL);
1707#else
1708	/* can not support in nommu mode */
1709	return -EINVAL;
1710#endif
1711}
1712#endif
1713
1714#ifdef __ARCH_WANT_SYS_VFORK
1715SYSCALL_DEFINE0(vfork)
1716{
1717	return do_fork(CLONE_VFORK | CLONE_VM | SIGCHLD, 0,
1718			0, NULL, NULL);
1719}
1720#endif
1721
1722#ifdef __ARCH_WANT_SYS_CLONE
1723#ifdef CONFIG_CLONE_BACKWARDS
1724SYSCALL_DEFINE5(clone, unsigned long, clone_flags, unsigned long, newsp,
1725		 int __user *, parent_tidptr,
1726		 int, tls_val,
1727		 int __user *, child_tidptr)
1728#elif defined(CONFIG_CLONE_BACKWARDS2)
1729SYSCALL_DEFINE5(clone, unsigned long, newsp, unsigned long, clone_flags,
1730		 int __user *, parent_tidptr,
1731		 int __user *, child_tidptr,
1732		 int, tls_val)
1733#elif defined(CONFIG_CLONE_BACKWARDS3)
1734SYSCALL_DEFINE6(clone, unsigned long, clone_flags, unsigned long, newsp,
1735		int, stack_size,
1736		int __user *, parent_tidptr,
1737		int __user *, child_tidptr,
1738		int, tls_val)
1739#else
1740SYSCALL_DEFINE5(clone, unsigned long, clone_flags, unsigned long, newsp,
1741		 int __user *, parent_tidptr,
1742		 int __user *, child_tidptr,
1743		 int, tls_val)
1744#endif
1745{
1746	return do_fork(clone_flags, newsp, 0, parent_tidptr, child_tidptr);
1747}
1748#endif

在用户态调用fork()，无论使用的是fork、vfork还是clone，底层使用的都是do_fork()

（上篇完）