Write documents of the program.

Add README.md on the design of the whole program, and how its every
part(listener, filter) works, finally how to compile and use them.

Besides, notes.md records the things and technology learned in this
program, such as how to read kernel src, how the pthread_create/fork/
clone syscall works on processes and threads, the techs used to make
docker container works well, and books to be read. Good good study,
day day up.

1 files changed, 318 insertions, 0 deletions

diff --git a/notes.md b/notes.md
new file mode 100644
index 0000000..932e811
--- /dev/null
+++ b/notes.md
@@ -0,0 +1,318 @@
+# 背景说明
+
+本文档对[godo](https://git.qin-juan-ge-zhu.top/godo)编写过程中新了解到的技术、遇到的问题进行简要说明，以备所需。
+
+# 系统调用
+
+As is universually acknowledged, 操作系统、尤其是类 Unix 操作系统，以系统调用的形式对应用程序提供服务。系统调用是名称，有系统调用号与之对应（同一版本的内核在不同架构的 cpu 上，系统调用号可能不一样）。有的时候我们需要了解一些内核行为，但却不知道从何下手。可以通过查看内核源码来学习。
+
+系统调用可以在源码中查找到。由于本项目使用的是 centos 7，内核版本 3.10.0-1160、cpu 为 x86-64 架构，兹以该版本内核为例说明。
+
+要查看 fork 的系统调用号，查看`arch/x86/syscalls/syscall_64.tbl`。想要查看其具体的实现，则在源码根目录下执行`grep -rInP "SYSCALL_DEFINE\d\(fork"`，其中 SYSCALL_DEFINE+数字是 kernel 中定义的宏，展开即完整的函数声明。通过这种查找办法，我们可以快速地定位内核中对系统调用的处理函数，查看其工作原理。查看其他的内核相关内容也可以采取类似办法，即先用 grep 定位大致范围、看都有什么地方用到，然后找到真正起作用的地方，读相关代码。
+
+使用这些系统调用有两种办法：
+
+- 在 C 语言中直接调用同名函数，但大概率经过了 glibc 的封装
+- 手动封装。如下：
+
+```c
+#include <stdio.h>
+#include <sys/syscall.h>
+#include <sys/types.h>
+#include <sys/wait.h>
+#include <unistd.h>
+
+int main(){
+    pid_t pid = syscall(SYS_fork);
+    // syscall是一个变参函数，第一个参数是系统调用号，接下来的是系统调用的各个参数
+    // syscall定义在 unistd.h
+    // SYS_fork定义在 sys/syscall.h
+    if(pid == 0) {
+        printf("Child!\n");
+    } else {
+        printf("Parent!\n");
+    }
+    return 0;
+}
+```
+
+这种封装方式与经常被用来当作 os 教材的 Linux-0.11/0.12 有所区别。Linux-0.11 环境上，unistd.h 大致如下：
+
+```c
+#ifndef _UNISTD_H
+#define _UNISTD_H
+
+...
+#include <sys/stat.h>
+#include <sys/times.h>
+#include <sys/utsname.h>
+#include <utime.h>
+
+#ifdef __LIBRARY__
+
+#define __NR_setup      0       /* used only by init, to get system going */
+#define __NR_exit       1
+#define __NR_fork       2
+#define __NR_read       3
+#define __NR_write      4
+#define __NR_open       5
+#define __NR_close      6
+...
+
+#define _syscall0(type,name) \
+  type name(void) \
+{ \
+long __res; \
+__asm__ volatile ("int $0x80" \
+        : "=a" (__res) \
+        : "0" (__NR_##name)); \
+if (__res >= 0) \
+        return (type) __res; \
+errno = -__res; \
+return -1; \
+}
+
+#define _syscall1(type,name,atype,a) \
+type name(atype a) \
+{ \
+long __res; \
+__asm__ volatile ("int $0x80" \
+        : "=a" (__res) \
+        : "0" (__NR_##name),"b" ((long)(a))); \
+if (__res >= 0) \
+        return (type) __res; \
+errno = -__res; \
+return -1; \
+}
+
+...
+#endif /* __LIBRARY__ */
+...
+
+#endif
+```
+
+可以看到，Linux-0.11 上，封装的一般方法为：
+
+```c
+#define __LIBRARY__ // 一定要在unistd.h之前
+#include <unistd.h>
+#include <stdio.h>
+
+syscall0(int, fork); // 宏替换后这就是个名为fork的函数的具体实现了
+int main() {
+    if(fork() == 0) {
+        printf("Child!\n");
+    } else {
+        printf("Parent!\n");
+    }
+    return 0;
+}
+```
+
+但是无论如何，一般情况下不推荐手动封装，这不是 release 版该有的做法。
+
+此外，从汇编代码来看，Linux-0.11 所用的 80386 芯片，不提供专门的系统调用指令，因而该系统使用的是`int 0x80`中断指令，通过注册中断处理函数进行对应处理；而现代 x86 提供了专门的 syscall 指令，Linux 系统直接用该指令进行系统调用。
+
+## 系统调用中的进程与线程
+
+一般地，在 Linux 系统上，我们以 pid 指代进程号，而进程可以有多个线程。很显然，真正被调度执行的单元应该是线程，换言之，**是 thread 而非 process 真正地对应着内核中 tasks 表里的一个 task，而每个 task 才具有独一无二的 id**。
+
+### 常见系统调用的分析
+
+看看这个：
+
+```c
+extern int pthread_create (pthread_t *__restrict __newthread,
+                           const pthread_attr_t *__restrict __attr,
+                           void *(*__start_routine) (void *),
+                           void *__restrict __arg) __THROWNL __nonnull ((1, 3));
+```
+
+`pthread_create`函数的第一个参数，就是一个 pthread_t 类型的指针，处理后将 task 的 id 写到指针指向的区域。
+
+让我们来看一段简单的代码：
+
+```c
+// test.c
+#include <stdio.h>
+#include <pthread.h>
+#include <sys/syscall.h>
+#include <sys/types.h>
+#include <unistd.h>
+
+void *test(void *args) {
+    printf("Hello, I'm %d\n", getpid());
+}
+
+int main() {
+    pthread_t pthid;
+    int pid;
+    pthread_create(&pthid, NULL, test, NULL);
+    printf("main: thread %ld\n", pthid);
+    pthread_join(pthid, NULL);
+    if ((pid = fork()) == 0) {
+        printf("Hello, I'm %d\n", getpid());
+        return 0;
+    }
+    printf("main: child process %d\n",pid);
+    if ((pid = syscall(SYS_fork)) == 0) {
+        printf("Hello, I'm %d\n", getpid());
+        return 0;
+    }
+    printf("main: child process %d\n",pid);
+    return 0;
+}
+```
+
+当我们使用`strace ./test`来查看上述代码时，会发现情况如下：
+
+```c
+clone(child_stack=0x7f3dd28bbff0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f3dd28bc9d0, tls=0x7f3dd28bc700, child_tidptr=0x7f3dd28bc9d0) = 21756
+write(1, "main: thread 139903502108416\n", 29) = 29
+clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f3dd308e9d0) = 21757
+--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21757, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
+write(1, "main: child process 21757\n", 26) = 26
+fork()                                  = 21758
+--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21758, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
+write(1, "main: child process 21758\n", 26) = 26
+exit_group(0)                           = ?
++++ exited with 0 +++
+```
+
+从这样的输出里，我们可以清晰地看到，无论是`pthread_create`还是`fork`（指库函数），本质上都是封装了`clone`系统调用，即使 Linux 本身提供了专门的 fork 系统调用。也许这是 glibc 和 Linux 都想在添加功能的基础上保证代码兼容性？花开两朵各表一枝了属于是。
+
+这一结论也可以从 glibc 的代码中得到验证：
+
+```c
+// 文件 glibc-2.18/nptl/sysdeps/unix/sysv/linux/pt-fork.c
+pid_t
+__fork (void)
+{
+  return __libc_fork ();
+}
+strong_alias (__fork, fork)
+
+
+// 文件 glibc-2.18/nptl/sysdeps/unix/sysv/linux/fork.c
+pid_t
+__libc_fork (void)
+{
+  ... // 一堆不知所云的代码
+#ifdef ARCH_FORK
+  pid = ARCH_FORK ();
+#else
+# error "ARCH_FORK must be defined so that the CLONE_SETTID flag is used"
+  pid = INLINE_SYSCALL (fork, 0);
+#endif
+  ... // 又是一堆不知所云的代码
+}
+
+// 文件 glibc-2.18/nptl/sysdeps/unix/sysv/linux/x86_64/fork.c
+#define ARCH_FORK() \
+  INLINE_SYSCALL (clone, 4,                                                   \
+                  CLONE_CHILD_SETTID | CLONE_CHILD_CLEARTID | SIGCHLD, 0,     \
+                  NULL, &THREAD_SELF->tid)
+
+// 文件 glibc-2.18/sysdeps/unix/sysv/linux/x86_64/syscall.S
+
+/* Please consult the file sysdeps/unix/sysv/linux/x86-64/sysdep.h for
+   more information about the value -4095 used below.  */
+        .text
+ENTRY (syscall)
+        movq %rdi, %rax         /* Syscall number -> rax.  */
+        movq %rsi, %rdi         /* shift arg1 - arg5.  */
+        movq %rdx, %rsi
+        movq %rcx, %rdx
+        movq %r8, %r10
+        movq %r9, %r8
+        movq 8(%rsp),%r9        /* arg6 is on the stack.  */
+        syscall                 /* Do the system call.  */
+        cmpq $-4095, %rax       /* Check %rax for error.  */
+        jae SYSCALL_ERROR_LABEL /* Jump to error handler if error.  */
+        ret                     /* Return to caller.  */
+
+PSEUDO_END (syscall)
+```
+
+可以看到，fork 库函数实际上是掉入了`__libc_fork`，在经过各种处理之后，如果 glibc 中该平台的相关代码里定义了 ARCH_FORK 宏，则调用之；否则会直接调用`INLINE_SYSCALL`（这是 glibc 各个平台的代码里都有的宏）；而如果直接调用`syscall`函数手动封装系统调用，则调用什么就是什么。`syscall`函数调用过程涉及延迟绑定等问题，就不是这里的重点了，而且我也没太搞明白，有机会单开一篇吧。
+
+### 进程与线程
+
+对于一个进程而言，它有很多线程，每个线程有一个号，但整个进程都有主线程的号，称为 tgid，只有一个 tgid 能真正地代表一个进程，而 pid 事实上是 task 的编号。
+
+对于 netlink connector 而言，它听到的 fork 并不是 fork，而是 clone；对于 audit，也只能听到 clone 而听不到 fork。这是因为在内核中，fork 也是通过调用 clone 的处理函数来进行的。clone 创建的是一个 task，至于具体是进程还是线程，取决于用的 flag 参数，参见 manual 手册。
+
+因而，无论使用 connector 还是 audit，拿到的都是 pid，只不过 connector 可以直接拿到 tgid、据此确定是进程还是线程，而 audit 只能拿到 pid，需要从 clone 的参数里查看是进程还是线程，且拿不到 tgid。这也就是我在项目中选择使用 connector 听进程消息的原因。
+
+干巴巴说了这么多，其实就是想说，pid 也许在不同的语境下有不同含义。
+
+# docker 使用的技术
+
+## cgroup
+
+Linux 下用来控制进程资源的东西。没学明白，留缺。姑且抄点书上的内容来占个位置吧。
+
+cgroup 是 control group 的简写，是 Linux 内核提供的一个特性，用于限制和隔离一组进程对系统资源的使用，也即做进程的 QoS。控制的资源主要包括 cpu、内存、block IO、网络带宽等。该特性自 2.6.24 开始进入内核主线，目前各大发行版都默认打开了该特性。
+
+从实现角度，cgroup 实现了一个通用的进程分组框架，而不同类型资源的具体管理由各个 cgroup 子系统实现。截至内核 4.1，已经实现的子系统及其作用如下：
+
+| 子系统     | 作用                                      |
+| ---------- | ----------------------------------------- |
+| devices    | 设备权限控制                              |
+| cpuset     | 分配指定的 cpu 和内存节点                 |
+| cpu        | 控制 cpu 占用率                           |
+| cpuacct    | 统计 cpu 使用情况                         |
+| memory     | 限制内存使用上限                          |
+| freezer    | 冻结暂停 cgroup 中的进程                  |
+| net_cls    | 配合 tc（traffic controller）限制网络带宽 |
+| net_prio   | 设置进程网络流量优先级                    |
+| huge_tlb   | 限制 huge_tlb 的使用                      |
+| perf_event | 允许 Perf 工具基于 cgroup 分组做性能监测  |
+
+cgroup 原生接口通过 cgroupfs 提供，类似于 procfs 和 sysfs，是一种虚拟文件系统。具体使用与分析参见《Docker 进阶与实战》。
+
+## namespace
+
+namespace 是将内核的全局资源做封装，使每个 namespace 拥有独立的资源，进程在各自的 namespace 中对相同资源的使用不会互相干扰。比如主机名 hostname 作为全局资源，执行 sethostname 系统调用会影响到其他进程；内核通过实现 UTS namespace，将不同进程分割在不同的 namespace 中，实现了隔离，一个 namespace 修改主机名不影响别的 namespace。
+
+目前内核实现了以下几种 namespace：
+
+| namespace | 作用                                |
+| --------- | ----------------------------------- |
+| IPC       | 隔离 System V IPC 和 POSIX 消息队列 |
+| Network   | 隔离网络资源                        |
+| Mount     | 隔离文件系统挂载点                  |
+| PID       | 隔离进程 ID                         |
+| UTS       | 隔离主机名和域名                    |
+| User      | 隔离用户 ID 与组 ID                 |
+
+对 namespace 的操作主要通过`clone/setns/unshare`三个系统调用来实现。详细的使用也不写了，没用过的东西就不全抄。记得读书和自己实验，补到这里。
+
+### 文件系统
+
+众所周知，docker 的文件系统是分层的，有镜像文件等一堆东西。文件系统分为若干层，在开启 docker 的时候会被联合挂载到同一个点下，作为 docker 的根目录。这叫做联合挂载，即将多个目录和文件系统挂载到同一个目录下，其中可能有覆盖等。
+
+docker 进程运行在宿主机的内核上，但是根文件系统又要用 docker 自己挂载的目录，且后来的进程也需要进入该目录。这里采用的技术是 pivot_root，该系统调用允许进程切换根目录。
+
+在根目录挂载完成之后，docker 拉起一个初始 shell（正如 Linux-0.11 启动的时候也会有一个 shell 干活），这是 docker 中第一个进程，它调用 pivot_root 切换根目录。在切换完成之后，当我们执行 docker exec 时，这是一个 docker 的新的进程，但该进程不再 pivot_root，而是打开第一个进程的 namespace，通过 setns 系统调用，将自己的 namespace 设置为与其相同。由于 mnt 的 namespace 的存在，进程的根目录也就与第一个进程一样了。
+
+# 书籍列表
+
+**毕业之前读完这些属实是有点难为人了，一个比一个硬，一次性啃完能给我门牙崩了；但是定点投放耗材市场之后，估计也不会有啥精力琢磨这些玩意了**。能读一点是一点吧。
+
+感觉自己现在已经染上班味了，绝症，没得治。
+
+- SRE：Google 运维解密
+- Linker and Loader
+- 有空自己解析一下 ELF？
+- Docker 进阶与实战
+- containerd 原理剖析与实战
+- Linux 内核源码情景分析
+- [LFS](https://www.linuxfromscratch.org/lfs/) 网站，自己从软件包开始搭建 Linux
+- 构建嵌入式 Linux 系统
+
+也许我应该把它们列入进阶版：
+
+- gcc 技术大全
+- 黑客调试技术大全