本文主要是介绍跟我一起玩《linux内核设计的艺术》第1章（四）——from setup.s to head.s，这回一定让main滚出来！（已解封），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
看到书上1.3的大标题，以为马上就要见着main了，其实啊，还早着呢，光看setup.s和head.s的代码量就知道，跟bootsect.s没有可比性，真多……这确实需要包括我在内的大家多一些耐心，相信见着main后，大家的信心和干劲会上一个台阶，加油！
既然上篇已经玩转gdb，接下来的讲解肯定是边调试边分析书上的内容，纯理论讲解其实我并不在行。
setup.s：
目标：争取把setup.s讲完
==坑一==：接下来,setup.s有个大坑等着读者，关于把内核程序从0x10000复制到0x00000：
>do_move:
mov es,ax ! destination segment
add ax,#0x1000
cmp ax,#0x9000
jz end_move
mov ds,ax ! source segment
sub di,di
sub si,si
mov cx,#0x8000
rep
movsw
jmp do_move
本能反应是，movsw每次移动2字节（1个字），移动次数0x8000也就是32k次，那总共移动2B×32K=64KB……啥？才64KB？
当然，稍细心点的读者立马看到jmp do_move，我们知道jmp是无条件跳转语句，也就是说，这是二重循环嵌套，ax从0开始每次累加0x1000，总共循环8次后跳转end_move，因此这次内核大搬迁的总大小应该是2B×32K×8=512KB。其中ax累加顺便就把段寄存器ds对应的目的地址也累加。
问题来了，关于内核（system模块）当初图1-12不是说好的：“bootsect调用read_it将软盘第六扇区开始约240个扇区的system模块加载至内存的SYSSEG（0x10000）处往后的120KB空间中。”况且，bootsect.s的开头就明确了SYSSIZE = 0x3000，并且注释也明确了0x30000 bytes = 196kB, more than enough for current versions of linux。说了当前版本linux内核大小不会超过196KB，为啥还要复制512KB呢？
如果你从来没思考过这个问题，那说明学东西还是不够仔细。bootsect.s后面还有这段话：
! NOTE! currently system is at most 8*65536 bytes long. This should be no
! problem, even in the future. I want to keep it simple. This 512 KB kernel size should be enough……
也就是说，这段内核迁移代码，是考虑到future的情况，未来要保持简洁，永远不让内核超过512KB，这段代码就永远有效。
==坑二==：1.3.2一开始就给读者来个下马威：GDT\GDTR、IDT\IDTR、LDT、TSS、LGDT
(＃￣～￣＃)，感觉就是，看了跟没看一样……
根据书上的解释，可以做如下对比总结：
| GDT：全局段描述表 | LDT：局部描述表 | IDT：中断描述表 |
| GDT存了很多个全局段， 每个段对应了一个进程入口地址 | LDT存了很多个任务task段 | IDT存了很多中断服务程序的入口地址 |
| GDT表中每个描述符对应一个任务task，每个任务又由局部描述符表LDT和任务状态段TSS来描述 | IDT每个描述符就直接是入口地址 | |
| GDTR存GDT的基地址 | LDTR存LDT的基地址 | IDTR存IDT的基地址 |
好，是不是清晰很多了。接下来看setup.s对应的GDT\GDTR、IDT\IDTR初始化实现。
>gdt:（全局段描述符表）
.word 0,0,0,0 ! dummy
.word 0x07FF ! 8Mb - limit=2047 (2048*4096=8Mb)
.word 0x0000 ! base address=0
.word 0x9A00 ! code read/exec
.word 0x00C0 ! granularity=4096, 386
.word 0x07FF ! 8Mb - limit=2047 (2048*4096=8Mb)
.word 0x0000 ! base address=0
.word 0x9200 ! data read/write
.word 0x00C0 ! granularity=4096, 386
idt_48:
.word 0 ! idt limit=0
.word 0,0 ! idt base=0L
gdt_48:（全局段描述符表寄存器）
.word 0x800 ! gdt limit=2048, 256 GDT entries
.word 512+gdt,0x9 ! gdt base = 0X9xxxx
先看GDT表的初始化过程。我们发现，gdt：初始化过程的顺序，和图1-18刚好是反的：
而GDTR的初始化gdt_48，也是相反的。
我们知道GDT表存储着全局段描述符，而GDTR存储着GDT的基地址。它们都是小端模式存储法。即高字节保存在高位，低字节保存在低高位。相当于权位与地址为直接对应。那么既然从低位开始初始化，当然首先保存低位，比如gdt_48:中先出现0x800，再比如gdt：中先出现0x7ff。至于为什么图1-18中把gdt三个描述符从下面往上面画，估计也是作者为了个小端模式的逻辑保持一致，本人觉得其实没这个必要。
好了，核心问题来了。你说gdt:是全局段描述符表，没问题，但对于不太精通汇编的读者来说，.word 512+gdt,0x9到底是啥意思？初步分析我们倒是知道，这里512对应0x200，也就是setup的基地址0x90200。那么gdt是啥？我们看看setup反汇编结果：
>12d: e4 64 in al,0x64
12f: a8 02 test al,0x2
131: 75 f6 jne 0x129
133: c3 ret
...
13c: ff 07 inc WORD PTR [bx]
13e: 00 00 add BYTE PTR [bx+si],al
140: 00 9a c0 00 add BYTE PTR [bp+si+0xc0],bl
144: ff 07 inc WORD PTR [bx]
146: 00 00 add BYTE PTR [bx+si],al
148: 00 92 c0 00 add BYTE PTR [bp+si+0xc0],dl
14c: 00 00 add BYTE PTR [bx+si],al
14e: 00 00 add BYTE PTR [bx+si],al
150: 00 00 add BYTE PTR [bx+si],al
152: 00 08 add BYTE PTR [bx+si],cl
154: 14 03 adc al,0x3
156: 09 00 or WORD PTR [bx+si],ax
0x13c开始是明显的gdt初始化开始的片段（就是数据初始化，不是汇编指令，因此右边写的东西可以当乱码而无视）。在0x154这个地方，就是.word 512+gdt,0x9的编译结果。根据小端模式换算，原来512+gdt被编译器计算出结果是0x0314。而512对应0x200，于是gdt的值就应该是0x314－0x200 = 0x114。也就是说gdt = 0x114。当你删除gdt：后面部分内容时，编译后结果不变，因此推测512+gdt中的gdt应该就是代码偏移量。
但是，当我们加上首代码行号后（数据段占据了0x20），0x114＋0x20 = 0x134，可是反汇编里没有0x134这行，为啥？如果你会用hexdump查看具体部分就会发现，setup从0x134~0x13b全是0，于是这部分内容被objdump用省略号雪藏了，其中就包括了重要的gdt的起始语句：.word 0,0,0,0。4个全0的“字”刚好对应8个全0的字节，而0x134~0x13b刚好是8行。于是，gdt：理想的反汇编结果，应该是这样的：
>12d: e4 64 in al,0x64
12f: a8 02 test al,0x2
131: 75 f6 jne 0x129
133: c3 ret
>134: 00 00 ！.word 0，
135: 00 00
136: 00 00 ！.word 0，
137: 00 00
138: 00 00 ！.word 0，
139: 00 00
13a 00 00 ！.word 0
13b: 00 00
13c: ff 07 inc WORD PTR [bx]
13e: 00 00 add BYTE PTR [bx+si],al
140: 00 9a c0 00 add BYTE PTR [bp+si+0xc0],bl
144: ff 07 inc WORD PTR [bx]
146: 00 00 add BYTE PTR [bx+si],al
148: 00 92 c0 00 add BYTE PTR [bp+si+0xc0],dl
14c: 00 00 add BYTE PTR [bx+si],al
14e: 00 00 add BYTE PTR [bx+si],al
150: 00 00 add BYTE PTR [bx+si],al
152: 00 08 add BYTE PTR [bx+si],cl
154: 14 03 adc al,0x3
156: 09 00 or WORD PTR [bx+si],ax
事实上，由于全局段描述符表gdt：本来就是setup的组成部分，因此在图1-18的内存条图标中天然就排在setup的末尾，而gdt_48（GDTR）这个全局描述符表寄存器，也跟随setup的执行而被初始化。
==坑三==：1.3.3贴出了setup.s开启A20的代码，但对代码没做过多解释。
>call empty_8042 ！输入缓冲器空否？
mov al,#0xD1 ! command write
out #0x64,al ！将值0xD1写入端口0x64，即写入8042的状态寄存器
call empty_8042 ！输入缓冲器空否？
mov al,#0xDF ! A20 on
out #0x60,al ！将值0xDF写入端口0x60，即写入8042的输出端口P2
……
>empty_8042:
.word 0x00eb,0x00eb
in al,#0x64 ! 8042 status port 读取端口0x64，即读取8042的状态寄存器
test al,#2 ! is input buffer full? bit1=1吗？
jnz empty_8042 ! yes - loop bit1=1！
ret
这里涉及到汇编中in\out语句，它们是CPU通过端口读写指令实现对外设的操作。其中in表示读端口，out表示写端口。
关于8042，你可以理解成早期独立的或现在模拟的键盘控制器8042 芯片。通过设置键盘控制器的端口值来达到设置A20的目的。
而关于intel 8042芯片有两个端口，其中0x60为数据端口，0x64为命令控制端口。0x64对应12条命令，其中0xD1表示：准备写output端口。也就是说，out #0x64,al其实就是为后面开启A20做初始化准备的。而0x60作为数据端，那么0xDF就是作为数据（而非命令）传送到0x60端口，准确的讲0xDF = 11011111b应该叫设置字节。我们看到其中bit0 = 1，bit1 = 1，设置字节中最低的两位要同时为1，才能顺利开启A20。至于为什么这么设置，其他高位又是什么含义，不搞硬件的同学没必要深究了。（别别别刨根问底了暴露我的无知多没面子o(╯□╰)o，有脾气去下载intel 8042手册自己慢慢研究囧rz！！！）
不论是输入数据端口，还是控制端口，都需要call empty_8042实现对输入缓冲器空否的判断。事实上，empty_8042:中还真有大坑，尤其是对汇编不熟的童鞋而言。那就是关于tes
这篇关于跟我一起玩《linux内核设计的艺术》第1章（四）——from setup.s to head.s，这回一定让main滚出来！（已解封）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
