從系統加載中對編程模式的思考

序

    最近看的博文都是洋洋灑灑，昨天又看了篇上世紀初的文章，有點半白話的感受，原本是想給出這種風格，不過我以爲若是技術類文章用散文體或者武俠體，之後本身讀着不方便，給別人看也很晦澀凌亂。因此想一想仍是規規矩矩作人，把事情一件一件說明白比較好。

一、規定

    之前看程序，遇到別人設置的一個變量，總要問問爲何這個變量要設爲這個值，就好比開機啓動之後，MBR必定要加載到內存0x07c00處，是否是放到這裏有什麼好處。後來看的書稍微多一點，不少做者對於這類問題也不了了之，設計者也沒有給出明確的解釋，那麼知識的傳授者也沒有仔細解說的必要，因此做者就會推掉責任說，具體想知道爲何，直接給設計者發email。

    因此說，在沒有太好的解釋前，其實變量的某些值就是設計者的一種喜愛，就好像hadoop非得叫hadoop，而不叫「魚香肉絲」或者「宮保雞丁」。若是要是中國人作出了hadoop這種軟件，可能就會叫一些比較文雅的詞。固然我是吃貨。。。

    所以，不少規定（就如上面加載MBR的規定）實際上並無太多意義，或者只是在某個歷史時段有其意義，而隨着後面的新技術的發展，雖然可能爲了更好的兼容性把這個規定保留下來，但其已經失去了實際的意義，同時，後面的設計還要爲前面的設計買單。

二、逐層迭代

    俗話說：一口吃不成個胖子。我以爲操做系統的加載就很好地應證了這句話。操做系統用最少的MBR，一層一層地加載到內存中，最後把全部須要的功能都帶入內存，每次的迭代，都是經過（地址，程序長度）的形式加載入內存，以少許的代價，帶來巨大的收穫。

    對於程序開發也是如此。看到知乎上一篇關於如何一次就能產生完美產品的文章，裏面說產品都是在不斷迭代中逐漸趨於完美，軟件中老是有未被發現的bug。所以，不管從操做系統仍是軟件開發中，均可以總結出迭代的特色——先作一點點，讓其保持正確；擴展功能，讓其保持正確。兩個步驟循環往返，每次都用小代價來得到高回報。

三、模塊化思想

    操做系統有衆多複雜的功能，如何讓這些功能，能夠相互協調，而又相互分散。就好像一個團隊，團隊中的每一個個體相似於一個功能模塊，就好像每一個人有本身的性格特色和思惟模式，模塊也有本身的行爲模式，可是不管模塊有什麼特色，提供給系統的功能都是一致的，即每一個個體給團隊的解決方案是一致的。能夠看出，模塊化能夠有效減小修改對整個系統的影響，即團隊的一我的離開，只有團隊協調者功能受影響，其餘人都不受影響。

    而對於操做系統來講，就是全部的I/O都被調用接口封閉起來，操做系統只能看到接口，而實際的設備處理都在其自身的子環境中封閉運行，對外提供輸入和輸出端口。

四、整體佈局與單線操縱

    不管是多線程仍是多進程，咱們始終都須要一個祖先來統領整個系統，祖先或者爲全部活動的發起者，或者爲全部活動的監聽者——由於在某個肯定的時間點只有你能執行、看到、啓動僅僅一個程序，某個時間點你只能按一次鍵盤，除非你在某個其餘時空有分身。

    所以，程序設計時咱們須要一個源頭，而源頭定了，那後面的任務就只能由這個源頭來承擔，或者由源頭的子孫來承擔。咱們也就能夠被解放，去啓動另外一個源頭。

    從上面來講，就像linux中的init進程，init是老大，咱們是init的老大，對於你面前的計算機，只有你是老大。