跳到主要內容

Book review: System Software 系統程式

今天跟大家推荐一本由金門大學的陳鐘誠教授所撰寫的系統程式教科書，書名叫作，嗯...就叫作"系統程式"。:)
因為小弟一直對系統程式非常有興趣，所以只要看到有什麼新鮮的東西，不管書籍或文章，必定都會儘可能地加以拜讀。但是講解系統程式的許多作者，往往才高八斗，很多時候一個段落裏面就提到了數個我們可能之前都沒有過的概念與名詞。很多愛好者都是在各種模糊中努力打滾了許久，才慢慢獲取一些基本概念，但其實我們可以不用這麼辛苦。
這本書的最大優點就是將許多看似神祕複雜的概念簡化再簡化，直到不能再簡化了為止，然後讓你看到：
1. CPU如何設計與實作其虛擬機
2. assembler如何設計與實作
3. Linker與Loader如何設計與實作
4. compiler如何設計與實作
當我閱讀到書中所設計的極簡版CPU0時，心中不免有些疑問，"天啊，買錯書了，這本書太過基礎了..."，但很快地，當我繼續跟著作者一步一步的實現出assembler、compiler、virtual machine，並且用自製的compiler去編譯source code為assembly code，然後再用assembler去組譯assembly code為執行檔，最後在CPU0的虛擬機上跑出1+1=2的結果時，真是令人興奮啊！！
於是，我們可以用很短的時間(我大約花了兩周的時間閱讀並實驗書中的實作)就獲得一個具體而微的計算機系統，並了解了重要組件之間的合作關係。總的來說，這本書值得那些想了解神祕的系統程式的愛好者閱讀，也值得要寫教科書的作者學習，看看要如何以簡單的方式解說複雜的系統。
講完了優點，來講缺點...有些部份簡略的有些過頭了，應該再加入一點解釋，比如說compiler的步驟為何要切割成數個？沒碰過compiler的學生大概很難理解為何會需要abstract syntax tree吧？另外程式碼的部份，應該可以教導學生在面對較大結構的程式時，要如何進行切割，適當地引入一點C的慣用法，畢竟系統程式中，以C為大宗，熟悉其慣用法也是蠻重要的，舉例來說，很多地方用了超巨大的switch case，如果試著用table of function pointers或structure with callback funcion去化簡主結構的邏輯，就更能凸顯主結構的核心流程了。
當然啦，由於這本書是設計給一般資訊科系約大二時的課程所用，所以目的在於教育用途，如果想看到"真實的"系統的話，就必須再額外深入學習各個領域，然後...嗯， 學海無涯，Keep walking. :P
標籤：

留言

張貼留言

這個網誌中的熱門文章

誰在呼叫我？不同的backtrace實作說明好文章

今天下班前一個同事問到：如何在Linux kernel的function中主動印出backtrace以方便除錯？ 寫過kernel module的人都知道，基本上就是用dump_stack()之類的function就可以作到了。但是dump_stack()的功能是如何作到的呢？概念上其實並不難，慣用手法就是先觀察stack在function call時的變化(一般OS或計組教科書都有很好的說明，如果不想翻書，可以參考 這篇 )，然後將對應的return address一層一層找出來後，再將對應的function名稱印出即可(透過執行檔中的section去讀取函式名稱即可，所以要將KALLSYM選項打開)。在userspace的實作可參考Jserv介紹過的 whocallme 或對岸好手實作過的 backtrace() ，都是針對x86架構的很好說明文章。 不過從前面兩篇文章可以知道，只要知道編譯器的calling convention，就可以實作出backtrace，所以是否GCC有提供現成的機制呢？Yes, that is what __builtin_return_address() for!! 可以參考這篇 文章 。該篇文章還提到了其他可以拿來實作功能更齊全的backtrace的 程式庫 ，在了解了運作原理後，用那些東西還蠻方便的。 OK，那Linux kernel是怎麼做的呢？就是用頭兩篇文章的方式啦~ 每個不同的CPU架構各自手工實作一份dump_stack()。 為啥不用GCC的機制？畢竟...嗯，我猜想，除了backtrace以外，開發者還會想看其他register的值，還有一些有的沒的，所以光是GCC提供的介面是很難印出全部所要的資訊，與其用半套GCC的機制，不如全都自己來~ arm的實作 大致上長這樣，可以看到基本上就只是透過迭代fp, lr, pc來完成： 352 void unwind_backtrace (struct pt_regs * regs , struct task_struct *tsk) 353 { 354 struct stackframe frame ; 355 register unsigned long current_sp asm ( "...
13 則留言
閱讀完整內容

淺讀Linux root file system初始化流程

在Unix的世界中，file system佔據一個極重要的抽象化地位。其中，/ 所代表的rootfs更是所有後續新增file system所必須依賴前提條件。以Linux為例，黑客 Jserv 就曾經詳細說明過 initramfs的背後設計考量 。本篇文章不再重複背景知識，主要將追蹤rootfs初始化的流程作點整理，免得自己日後忘記。 :-) file system與特定CPU架構無關，所以我觀察的起點從init/main.c的start_kernel()開始，這是Linux作完基本CPU初始化後首先跳進的C function(我閱讀的版本為 3.12 )。跟root file system有關的流程羅列如下： start_kernel()         -> vfs_caches_init_early()         -> vfs_caches_init()                 -> mnt_init()                         -> init_rootfs()                         -> init_mount_tree()         -> rest_init()                 -> kernel_thread(kernel_init,...) 其中比較重要的是mnt_int()中的init_rootfs()與init_mout_tree()。init_rootfs()實作如下： int __init init_root...
張貼留言
閱讀完整內容

中文試譯：Load-time relocation of shared libraries

作者： eliben 原文連結： http://eli.thegreenplace.net/2011/08/25/load-time-relocation-of-shared-libraries/ 共享庫的載入時重定位 這篇文章的目的在解釋現代作業系統如何讓共享庫在載入時的連結動作發生。我們聚焦在32位元的x86 Linux上頭，但相同的原則在其他的作業系統與CPUs上一樣適用。 要注意的是，共享庫有許多不同的名字 - 共享庫（shared libraries）,共享物件（ shared objects）,動態共享物件（ dynamic shared objects (DSOs)）,動態連結庫（ dynamically linked libraries（如果你習慣的是Windows的環境，就知道這是所謂的DLL））。為了一致性，我在整篇文章中會使用"共享庫"這個字眼。 載入可執行檔 如同其他支援虛擬記憶體的作業系統，Linux將可執行檔載入到一個固定的記憶體位址。如果我們檢視任意一個可執行檔的ELF header，我們將可發現一個Entry point的位址： $ readelf -h /usr/bin/uptime ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 [...] some header fields Entry point address: 0x8048470 [...] some header fields 這是由linker所放置的，可告訴作業系統要從何處開始執行此執行檔[1]。如果我們用GDB載入程式並觀察0x8048470的位址，我們將可看到.text segment的第一個被執行的指令。 這代表的是，當linker連結可執行檔時，會把全部的內部符號引用的位址都確定下來（function以及data），確定它們的固定的、最終的位址。Linker本身會對自己進行一些relocation[2]，但最終的結果不會有任何的relocation。 講啥啊？注意，我在上段文中特別強...
5 則留言
閱讀完整內容