人生海海

大家都知道 git 有 staging area. 的確是,在台灣玩git的人真的是比較多. mercurial 則是有MQ extension 來實現同樣的功能. MQ =  Mercurial Queues ,他的根本意義是,在work copy 跟 repo 之間,實作一個queue 的概念. 有了這個queue 的實作,使用者可以把它當作staging area 來使用,也可以把它當作 patch manage 來使用 , 當然用法不只如此,一旦知道了使用方法後,他的通用性可以讓使用者自由發揮創意. 我很喜歡進行小步進的開發,有可能一個小功能我會再切分更細的工作元素.可是我不希望repo的 log 上滿滿的都是瑣碎的提交,我希望提交的內容是一個完整的功能,或是一個完整的演算法實作,或是一個完美的 bug resolv 方案,因此我的需求就是將一整個串的小修改紀錄變成"一個 "提交. git 的 local branch 可以很方便的做到這樣.我只要開出一個新分支,改個幾行就commit , 等到功能測試完成,我用Squashed merge 模式 來 merge 到主幹.這樣主幹只會有一個commit 紀錄. 可是其實我還是對mercurial 有愛.如果能在mercurial 下做事,自然是盡量在mercurial 下做.如果我沒有 MQ , 我必須clone 兩份 mercurial repo ,一分作小步進的commit , 等到完成後,用diff 輸出所有的差異,commit 到另一份 repo ,接著 push / pull 到主幹 幹! 真是麻煩. 所以我想到可以用MQ來幫我做. 首先,要啟動 MQ ,請修改 repo 下的.hg/hgrc or ~/mercurial.ini [extensions] mq = 這樣就可以了. 有了 MQ 後要怎麼做? 作業概念上是依照以下順序. 新建一個queue --> 修改檔案內容 --> 把變動送進 queue ---> 修改檔案內容 --> 把變動送進 queue ---> 修改檔案內容 --> 把變動送進 queue ---> .......---> 完成,把queue 的內容送進r...

當你沒有要傳入init ram fs 的記憶體位址給kernel,可以不需要準備ATAG_INITRD 和ATAG_RAMDISK .反之,若你需要傳入init ram fs 位址給kernel,那就要準備這兩個Atag ATAG_CMDLINE 使用空間大小的計算方法: atag header size + ( strlen( (char *) argement string ) + 3 ) / 4; 通常我們取得的kernel 命令參數是C語言形式的字串,每個字母8位元,以0結尾.而Atag 使用空間大小的值則是以32位元為單位,所以字串長度要+3再除4

pull / push ,是分散式版本控制系統的指令 對於mercurial 中,執行pull 操作,把對方的changesets 抓回來時,"預設"不自動進行merge.抓回來的changeset 中如果有新的分支,pull 後自己的儲存庫就會多出一個新分支,名字跟遠端的那個新分支一樣.若是changeset是某一個支線的變更,則mercurial 會在那個支線生出新的head.push 也是一樣的作法.這樣一來,你就必須自行檢驗一下抓回來的changeset 內容,然後自己merge,這樣的機制提供了一個檢驗跟反悔的機會.當然也得出比較多的工 而git 的pull ,預設是會自動merge的.push 也是一樣,預設會進行merge.所以你可以聽到看到很多git 的教學網站/前輩,都呼籲大家在git 環境裡,謹慎的使用pull/push 指令,因為一旦merge 時產生衝突,反而得花更多的工在解決衝突,建議是先用fetch 指令.git 的fetch 指令,會先把遠端的changeset 抓回來,抓回來的changeset 會開一個新分支暫放,你可以切換到新分支檢查與驗證抓下來的changeset,有信心後再將這個分支merge 到你本身.

原來 bzImage 是由setup.bin 跟 vmlinux.bin 綁起來製作而成的 可以使用以下關鍵字查詢更詳細的資料 google://"bzImage" "vmlinux.bin" "setup.bin" vmlinux.bin 就是整個linux kernel 的壓縮實體.setup.bin 則是負責在配置一些在執行vmlinux.bin之間該要做的硬體環境設定.沒錯,setup.bin的角色很像u-boot的一部分功能 Grub or Lilo 這類bootloader ,都會聰明的把setup.bin 跟vmlinux 分開,setup.bin 放在0x90000處,vmlinux.bin放在0x100000位置.詳細的分開知識,可以查詢 google://"grub" "0x90000" "0x100000" setup.bin 的實際工作內容,可以查詢 google://"header.S" "setup.ld" 對於要開發bootloader 的地球人來說,以上都是必備知識

首先,該看一下以下網址 http://www.simtec.co.uk/products/SWLINUX/files/booting_article.html 或者是Kernel 內附的文件 Documentation/arm/Booting ---------------------------------------------------------- 以下是個人心得 Arm 版本不是使用setup_header結構,而是一個所謂ATAG 的結構佇列,bootloader需要自行在記憶體中建立一個ATAG佇列.這個佇列的的開始位址,在bootloader 開始執行kernel的start code 前,放在Arm CPU 的R2暫存器內.(R1暫存器放機器型別代號) 每一個ATAG結構塊,都會有一個旗標顯示這個結構塊是屬於哪一種類型的ATAG ,像有ATAG_CORE壓,ATAG_MEM壓,ATAG_INITRD2等.一看名字就知道要幹嘛. 當我要把initrd/initramfs 的位置告訴kernel時,就可以利用ATAG_INITRD2這類型的ATAG.當我要把kernel command line 告訴kernel時,就可以利用ATAG_CMDLINE

一樣的,在setup_header 中,有一個欄位是cmd_line_ptr.這個欄位即是儲存了kernel 參數的C型態字串(就是0結尾拉),當然,在x86 old BIOS中,bootloader只能存取1M以下(真實模式嘛),所以cmd_line_ptr紀錄的也是真實模式的位址 好了,一樣可以參考Documentation / x86 / boot.txt

bootloader 的功能就是把copy kernel image,copy initrd/initramfs 到記憶體,還有kernel 參數放到記憶體,然後執行kernel.可以這麼說. 找出initrd/initramfs image    copy initrd/initramfs image 到記憶體 的工作,都是bootloader 負責 所以當bootloader 完成以上的工作時.bootloader 就要把initrd/initramfs 所處的記憶體位置告訴kernel. linux kernel 文件中對於這部份有一個專門文件,詳細指示開發bootloader的人類該怎麼做.這文件叫' boot protocol ',你可以 google://linux kernel boot protocol 來研讀這份官方文件. 有關中文的介紹部份,以下兩個連結值得參考 http://sakbk.pixnet.net/blog/post/30315621-initrd-and-initramfs http://blog.csdn.net/cherryloo/article/details/2096682 為免以上兩個連結失效,我將研讀的心得寫下來: --------------------------------------------------------------------- kernel code 中定義了一個 setup_header 結構( arch/x86/include/asm/bootparam.h).這個結構中有兩個欄位專門紀錄initrd/initramfs 的記憶體位置.當kernel 編譯完成後,此結構的位置會 固定 在zImage(or bzImage)檔案的最開頭位置(可詳閱header.S 這個檔案). 首先,bootloader copy kernel image 到記憶體,接著bootloader再copy initrd/initramfs image 到記憶體中.然後bootloader就把記憶體位置寫到setup_header結構記憶體中的兩個欄位. 最後,bootloader 跳躍到kernel 開始,開始執行kernel. 就這樣