啟動搬遷過程：

1、BIOS將磁盤引導塊程序bootsect讀入到內(nèi)存0x7c00，開始執(zhí)行指令；
2、bootsect將自己搬遷到內(nèi)存0x90000，跳到該段中的自己的下一條指令執(zhí)行；
3、bootsect將設備檢測安裝程序setup讀入到0x90200；
4、bootsect將內(nèi)核映像system讀入到0x10000，跳到setup頭部0x90200執(zhí)行指令；
5、setup獲取系統(tǒng)參數(shù)，依次保存在0x90000；
6、setup將system從0x10000搬遷到0x0000；
7、setup設置硬件寄存器和CPU狀態(tài)字寄存器，進入32位保護模式，跳到system頭部0x0000執(zhí)行指令。
8、開始執(zhí)行內(nèi)核映像中的指令。
9、內(nèi)核映像首部的指令（head.s）設置各個寄存器，加載中斷描述符表、全局描述符表，檢測芯片，
對16M內(nèi)存進行分頁。
10、執(zhí)行main程序。

閱讀三個匯編程序和注釋，很快就能了解到啟動引導程序在進入main函數(shù)前作了這些事情。
為什么要這樣搬遷和執(zhí)行呢？
簡單地講，內(nèi)核啟動搬遷過程是：bios裝載運行bootsect，bootsect裝載setup、system，運行setup搬遷system。bios的行為是已經(jīng)固定寫好燒在主板上bios芯片里的了。不是linus所控制的，也不是操作系統(tǒng)的范疇了。bios應該是和硬件架構(gòu)緊密相關(guān)的。所以為什么bios將bootsect讀到0x7c00這么
個怪地址，也沒有其它的好講了————對架構(gòu)我不懂。:(

?????? 在加載bootsect之前，bios從0地址開始加載了中斷向量表————這個是我們的匯編代碼中可以使用bios中斷功能的基礎。是在實模式中我們的原始武器和工具。按照一個中斷向量占四個字節(jié)，7c00前面如果都是中斷向量表的話，這里應該有7c00/4 = 7936個中斷向量了。應該沒有這么多吧？ 可能是有空余空間供擴展？ 不得而知。
?????? bootsect自己搬遷自己的行為，我沒有找到充分的理由。
setup被裝載到0x90200，system被裝載到0x10000,這些都沒有覆蓋到0x7c00＋512的空間，也就不會造成自己裝載的咚咚覆蓋了自己的指令代碼的危險。而這個bootsect的512字節(jié)大小，至今也沒有變化，也不應該是為后續(xù)擴展所保留的。從Linus講setup直接load到0x90200可以看出，這個512字節(jié)也應該是不會變大的————由于bootsect是由bios裝載的，變大了說明bios的代碼和行為都變化了，這個是不現(xiàn)實的。所以我能解釋的理由就是：linus覺得bios加載的地方不爽，所以特意把它挪到0x90000和setup放在一起。如果你知道這個bootsect搬遷的理由，請不吝告訴我

關(guān)于setup
setup被bootsect裝載到了0x90200，bootsect執(zhí)行完之后就執(zhí)行了setup代碼。setup被裝載到0x90200，而不是其它的地方，應該是由于system占用了0x10000～0x90000，而bootsect占用了0x90000～0x90200。由于0x7c00＋512地址以前的地方被bios占用了。因此setup可能的裝載的地方有：0x7c00＋512后面，或者0x90200后面。而在setup代碼的執(zhí)行過程中有一個動作，將system從0x10000搬遷到0地址。這樣，由于預留的512K大小的system必然把0～0x80000的內(nèi)存都覆蓋了。也就是說如果把setup裝載在0x7e00之后，則會發(fā)生自己的搬遷行為修改了自己的指令地址————這是不可以的。而且將setup裝載在0x7e00，則setup的大小受到限制，不能超過0x7e00到0x10000這塊地址。setup獲取的設備信息覆蓋了0x90000的bootsect的代碼。然后將system向0地址平移。這個動作覆蓋了系統(tǒng)中斷和0x7c00的bootsect。

這個時候為什么可以覆蓋中斷向量表呢？ 我想是基于這么幾個原因：
setup通過bios提供的這些工具能獲取的系統(tǒng)參數(shù)都已經(jīng)獲取并保存了，工具已經(jīng)沒用了。在后面進入保護模式后，也已經(jīng)不能通過中斷向量的方式來使用bios中斷了。前一個原因可以通過查看后面的匯編代碼得到證實：后面的代碼都沒有再調(diào)用bios中斷。第二個原因可以通過后續(xù)代碼的動作和注釋得到證實：setup位32位保護模式加載了全局描述符表，中斷描述符表。 后續(xù)發(fā)生中斷時，將通過中斷描述符表中的項映射到中斷處理代碼上去。這里面原來中斷向量的每一項應該是四個字節(jié)（我沒有記錯的話），而中斷描述符表中的項有八個字節(jié)————32位保護模式下，包含的中斷信息更多了。

關(guān)于system
system就是Linux的內(nèi)核了。內(nèi)核首部的head.s的指令其實應該還是算作引導程序。放在內(nèi)核中，而不是像setup一樣單獨編出來，估計是為了后續(xù)版本更方便的修改吧————畢竟內(nèi)存分頁、GDT、IDT之類的東西修改的可能性是很大的。

為什么將system從0x10000搬遷到0地址，書上也說了，好處是對于其中的代碼，線形地址和物理地址是一樣的，這樣子寫程序更方便一些————linus這樣說。實際上，我感覺不搬遷也沒有什么不行。代碼和數(shù)據(jù)的操作也應該沒有什么不方便，畢竟就是匯編里面也是使用的標號。或許還是我沒有理解到？

system加載了全局描述符表，中斷描述符表。中斷描述符表已經(jīng)說過了，用來映射中斷服務程序和中斷號的。全局描述符表，則是用來描述全局符號的。呵呵，這個解釋。全局描述符表是一個記錄各個任務的相應段信息的全局表。表中兩個字作為一個任務的描述項：局部描述符表LDT，任務狀態(tài)段TSS。局部描述符表指向某個具體任務的各個段信息（代碼段，數(shù)據(jù)&堆棧段）的結(jié)構(gòu)。任務狀態(tài)段TSS應該是用來記錄任務狀態(tài)進行任務調(diào)度用的吧？ 從這里看來，多進程的實現(xiàn)應該就是保存各個任務的上下文，進行切換和上下文處理吧。而上下文，也就是寄存器狀態(tài)、指令位置、數(shù)據(jù)狀態(tài)了。

head.s還對16M內(nèi)存進行了分頁。每4096字節(jié)的內(nèi)存分為一頁，用四個字節(jié)描述一頁（應該是四個字節(jié)的32位地址指向這一頁的首部吧）。然后1024個頁地址組成一個頁表，一個頁表占據(jù)一頁（1024×4＝4096）。一個頁表也就管理了1024×4096＝4M內(nèi)存。Linus的16M內(nèi)存即占用了四個頁表來描述。然后四個頁表的地址又寫到0地址開始的地方，占用了16字節(jié)，形成了頁目錄了。 頁目錄從0地址開始，頁表從0x1000開始。也即第0頁都是頁目錄了。按照Linus的這個處理，4096/4 × 4M ＝4G，也就是這個頁目錄的大小可以管理4G內(nèi)存了。不過如果真的初始化了4G的內(nèi)存頁，會出問題。4G內(nèi)存需要1024個頁表，一個頁目錄，供占用1025個頁面，這樣頁表就寫過了0x90000，要寫到1025×1024＝0x101000，比0x90200超過很遠了————后果就是現(xiàn)在寫到0x90200＋0x400×2＝0x90a00后面的全局描述符表和中斷描述符表了。中斷描述符表無所謂，反正是啞中斷。但是描述符表被破壞了，后面的就沒得玩了。

好了，全局描述符表（多任務的容器）建好了，內(nèi)存分頁也做好了。 就等main來打展身手了。

?