利用docker构建linux2.6.11

最近在看lkd和ulk，寻思配置一下编译环境能更好理解内容。

注意，使用容器的目的只是为了编译源码，因此，以下涉及编译相关的操作均为容器内操作，使用qemu运行为容器外操作，其他文件修改等操作在容器内外无明显影响，但是可能需要根据具体情况修改相对路径。

源码阅读环境

vim+ctags-universal+cscope

准备阶段

根据reddit的帖子，发现可以使用docker的debian/eol:sarge编译此版本，它默认安装的gcc版本为3.3.5，同时又支持安装2.95，这是README推荐的版本。但是我发现3.3.5版本可以正常编译，所以直接用默认版本编译了。

使用以下指令拉取并运行镜像

1	`docker run -v ./ulk:/ulk -it --name linux_build debian/eol:sarge`

在容器内补全编译环境

1	`apt-get update&&apt-get install ncurses-dev build-essential make gcc`

注意其指向的镜像源为archive.debian.org。国内访问速度可能较慢。

一个奇怪的情况

我的运行环境为amd64，而帖子提示似乎只能构建32位的kernel。所以起初我认为指定运行i386平台比较稳妥。而且还可以在这个环境里编译一些静态链接的程序，能直接打包进initramfs中就能运行，比较方便。

所以我添加了--platform参数来指定运行的平台。

1	`docker run -v ./ulk:/ulk -it --name linux_build --platform linux/386 debian/eol:sarge`

启动后使用uname -m查看后发现仍然是x86_64架构，与宿主机相同，这可能是docker的运行机制导致的。随后发现安装的软件均为x86架构的，而且软件均能正常运行。

但是其实我在最开始启动镜像时并未指定平台，根据我的环境，它应该默认启动amd64架构的镜像。检查后发现安装的软件同样为x86版本，也能正常运行。

这现象很奇怪，因为官网标记的这个镜像的架构只有linux/amd64与linux/arm/v5。使用docker manifest inspect debian/eol:sarge发现这个镜像其实同时支持386、amd64和armv5。

官网显示的OS/ARCH为amd64的架构的构建指令中包含的下载链接也含有386标识:https://github.com/debuerreotype/docker-debian-eol-artifacts/tree/bdf1728b9b8153c87c06af5f90ae64ebab1aedb9/sarge/i386。

考虑到linux架构特殊，不像Windows需要专门的WoW64子系统才能在64位上运行32位软件。所以此镜像的标记为amd64平台的镜像实际上应该运行的平台为386。

初次编译kernel

在容器内进入linux2.6.11的根目录，我的是/ulk/linux-2.6.11，运行

1	`make ARCH=i386 defconfig`

生成默认配置，目前环境应该只支持构建i386架构的kernel，如果尝试构建x86_64架构，会报错cc1: error: code model 'kernel' not supported in the 32 bit mode，可能需要在i386平台的容器内使用x86_64的交叉编译器进行编译，但是我不会在这个上古环境中安装，所以先跳过了。

编译内核镜像生成bzImage。

1	`make ARCH=i386 -j`

启用initramfs

只生成内核镜像，不启动一个shell的话几乎无法使用，所以我们要在编译内核镜像时让它打包一个cpio进镜像并以initramfs方式启动，方便测试我们编译的内核。

执行make ARCH=i386 menuconfig（不确定此时加不加ARCH的区别，但是我加了肯定不会错）进入可视化配置菜单，按照如下配置修改

Device drivers
block devices Initramfs source file(s)

其中需要填写一个initramfs的路径，我这里填写的路径是容器中的路径，为/ulk/initramfs.cpio。

构建initramfs

创建目录initramfs并进入，编写你想要的initramfs的结构。

我的initramfs配置

创建设备文件

创建目录mkdir initramfs/{bin,dev,etc,proc,sys}

我这里主要使用的是busybox的1.16.1的i486版本（这是我能找在官网找到的最老的符合需求的版本了），下载下来复制到bin/busybox，然后chmod +x bin/busybox

在dev中创建以下文件

cd dev/
mknod -m 600 console c 5 1
mknod -m 666 null c 1 3
mknod -m 666 random c 1 8
mknod -m 666 urandom c 1 9
mknod -m 666 zero c 1 5
mknod -m 666 full c 1 7
mknod -m 666 tty c 5 0
mknod -m 666 tty0 c 4 0
mknod -m 666 tty1 c 4 1
mknod -m 666 ttyS0 c 4 64

如果想要使用串口，需要启用kernel配置CONFIG_SERIAL_8250和CONFIG_SERIAL_8250_CONSOLE，其他具体的忘了。

编写init

由于目前处于初级阶段，所以init无需写的很复杂，生成足够的工具就足够了。

#!/bin/busybox sh

BB=busybox

$BB mount -t proc none /proc
$BB mount -t sysfs none /sys

/bin/busybox --install /bin

echo "Initramfs loaded successfully!"
exec /bin/sh

为了降低包体积，我们只在bin下创建busybox程序和一些dev文件并打包，其他程序在执行init程序时动态生成。

最终目录结构

initramfs
├── bin
│   └── busybox
├── dev
│   ├── console
│   ├── full
│   ├── null
│   ├── random
│   ├── tty
│   ├── tty0
│   ├── tty1
│   ├── ttyS0
│   ├── urandom
│   └── zero
├── etc
├── init
├── proc
└── sys

打包initramfs到bzImage

接下来进入initramfs目录，打包成cpio

1	`find . \|cpio -o -H newc > ../initramfs.cpio`

注意，在容器中，此cpio文件位于/ulk/initramfs.cpio，与之前在menuconfig中填写的路径相同。

接下来进行构建

1	`make ARCH=i386 -j`

不出意外的话即可构建成功，并生成bzImage到./arch/i386/boot/bzImage

接下来在宿主机中使用qemu运行

1	`qemu-system-i386 -kernel ./arch/i386/boot/bzImage -cpu pentium3 -m 512M -append "console=tty0"`

自动化构建

我们可以使用makefile简化打包cpio->重新编译bzImage->启动qemu这个过程，以下是参考

INITRAMFS_SRC := $(shell find initramfs/)
LINUX_SRC_ROOT := /ulk/linux-2.6.11
ARCH := i386
BUILD_CONTAINER := linux_build
BUILD_PREFIX := docker exec $(BUILD_CONTAINER)

qemu: bzImage
	qemu-system-i386 -kernel bzImage -cpu pentium3 -m 512M -append "console=tty0"

bzImage: initramfs.cpio
	$(BUILD_PREFIX) make -C $(LINUX_SRC_ROOT) ARCH=$(ARCH) -j
	docker cp -L $(BUILD_CONTAINER):$(LINUX_SRC_ROOT)/arch/$(ARCH)/boot/bzImage ./bzImage

initramfs.cpio: $(INITRAMFS_SRC)
	cd initramfs && find . |cpio -o -H newc > ../initramfs.cpio

.PHONY: bzImage qemu

由于makefile需要拉起qemu，所以需要在宿主机中运行。而kernel构建过程位于容器中，构建完成后又要通过docker cp复制出来bzImage。此过程中我们可能并不知道kernel源码目录，进行依赖分析可能较为困难，因此只能将bzImage标记为phony。

由qemu指定initramfs启动来减少编译时间

我们之前的思路是直接将initramfs打包进kernel镜像，便于移动和启动，但是后续开始写makefile后应该分别管理，从而加快编译速度。（其实是第一次打算使用-initrd时不知道为什么没有成功，才先采用打包的方法的。）

这是一个优化后的makefile

INITRAMFS_SRC := $(shell find initramfs/)
LINUX_SRC_ROOT := /ulk/linux-2.6.11
ARCH := i386
BUILD_CONTAINER := linux_build
BUILD_PREFIX := docker exec $(BUILD_CONTAINER)

qemu: bzImage initramfs.cpio.gz
	qemu-system-i386 -kernel bzImage -cpu pentium3 -m 512M -append "console=tty0" -initrd ./initramfs.cpio.gz

bzImage: 
	$(BUILD_PREFIX) make -C $(LINUX_SRC_ROOT) ARCH=$(ARCH) -j
	docker cp -L $(BUILD_CONTAINER):$(LINUX_SRC_ROOT)/arch/$(ARCH)/boot/bzImage ./bzImage

initramfs.cpio.gz: $(INITRAMFS_SRC)
	cd initramfs && find . |cpio -o -H newc |gzip > ../initramfs.cpio.gz

.PHONY: bzImage qemu

修复init拉起sh时的报错

如果在init脚本中直接拉起sh，会报错"bin/sh: can't access tty; job control turned off"并关闭高级控制，例如<C-c>、fg、bg等无法使用，经过查找发现一个解决方式是修改init脚本，添加setsid cttyhack sh。

#!/bin/busybox sh

BB=busybox

$BB mount -t proc none /proc
$BB mount -t sysfs none /sys

/bin/busybox --install /bin

echo "Initramfs loaded successfully!"
setsid cttyhack sh
exec sh

编译可以在此内核版本运行的代码

lkd书中有添加一个新的系统调用的例子sys_foo，为了能够测试，我们需要编译一个foo_syscall.c调用新添加的系统调用并输出。

#include <stdio.h>
#include <linux/unistd.h>
_syscall0(long, foo);

int main(){
	// it should print THREAD_SIZE
	printf("%ld\n",foo());
}

由于我们的initramfs中什么编译工具都没有，自然无法在里边编译这个程序。我们需要在容器中编译它，目前有两种方法：给initramfs添加动态库，或者将此程序静态链接。但是无论如何选择，都得编译musl库。

经过挑选，我找到了一个相对远古的但是看起来比较稳定的musl版本：1.0.0。但是构建动态库时会报错且无法生成动态库：

/usr/bin/ld: unrecognized option '-Bsymbolic-functions'
/usr/bin/ld: use the --help option for usage information

collect2: ld returned 1 exit status

查到一次提交修复了此问题，日期为2016-01-31 00:40:33 -0500，所以需要往后找新一些的版本。1.1.24编译的动态库会产生段错误，可能太新了。最终发现可以正常编译1.1.15版本。

构建musl库

1
2
3

./configure
make -j
make install

我们需要的文件位于lib/libc.so，将他复制到initramfs/lib/（可能需要创建lib目录）。另外，我们还需要ld.so，但是暂且按下不表。

写一个hello world，使用musl-gcc hello_world.c -o hello_world进行编译，发现可以运行，而且它的dynamic linker是/lib/ld-musl-i386.so.1。

1 2	`# readelf -l ./hello_world\|grep 'interpreter' [Requesting program interpreter: /lib/ld-musl-i386.so.1]`

我感觉它太长了，所以接下来在配置initramfs中的ld.so时给它改短点。

配置ld.so

我们先ln -s initramfs/lib/libc.so initramfs/lib/ld.so（ls -l发现musl的ld.so实际上是libc.so的软链接，甚至只有ld.so没有libc.so应该也可以运行？不知道这种用法是否在musl的方案中），此时，假如我们进入qemu虚拟机，它的ld.so位于/lib/ld.so，libc.so位于/lib/libc.so。

但是我们在容器中使用musl-gcc编译出来的可执行程序的动态链接器的路径是/lib/ld-musl-i386.so.1，当我们把这个可执行程序放在initramfs中显而易见由于ld.so的位置不同，动态链接的程序是不能正常运行的，因此需要修改它的动态链接器。目前我采用编译时修改dynaic-linker实现，当然对于已经编译的ELF文件，有nixos项目的patchelf可用。

1	`musl-gcc -Wl,-dynamic-linker=/lib/ld.so hello_world.c -o hello_world`

可以直接在容器中alias一个short ld.so name musl-gcc：alias sldmgcc="musl-gcc -Wl,-dynamic-linker=/lib/ld.so"
经过测试，作为一个动态链接的可执行程序，它可以在initramfs中运行。

此时的initramfs结构

initramfs
├── bin
│   └── busybox
├── dev
│   ├── console
│   ├── full
│   ├── null
│   ├── random
│   ├── tty
│   ├── urandom
│   └── zero
├── etc
├── init
├── lib
│   ├── ld.so -> libc.so
│   └── libc.so
├── proc
└── sys

编译自定义系统调用测试程序

我们前文展示了一个调用自定义系统调用的源码

#include <stdio.h>
#include <linux/unistd.h>
_syscall0(long, foo);

int main(){
	// it should print THREAD_SIZE
	printf("%ld\n",foo());
}

_syscall0(long, foo)是lkd书中展示的创建一个返回THREAD_SIZE的syscall：sys_foo。

我们在前文已经配置好了动态链接和编译环境，接下来可以着手编译这个测试程序了。

linux/unistd.h这个头文件属于linux源码的一部分，我们需要用到它的一些宏和定义等，所以我们需要在编译时手动指定头文件的导入目录

1	`sldmgcc foo_syscall.c -o foo_syscall -I<path-to-linux-2.6.11/include>`

1 2	`# readelf -l ./foo_syscall\|grep 'interpreter' [Requesting program interpreter: /lib/ld.so]`

将编译结果放入initramfs重新打包，启动qemu测试，可以看到成功执行代码。

1 2	`/ # foo_syscall 4096`

总结

linux2.6.11版本有些老旧，它并不支持很多现在的功能，而且很多实现细节上也与当下经过探索过的、更好的实现细节相去甚远：例如mutex lock，在此版本仍然利用binary semaphore实现，没有上锁后只有所有者才能解锁的概念，且尚未实现completion variable等针对更加细节场景优化方案。

另外我记得lkd一书是对着2.6.33讲解的，有部分内容存在差异，但是大体上和2.6.11差别较小。

总的来说此版本在代码组织，编译过程上相较于现在的内核没有较大的变化，还是值得学习的。