尋找最初的初衷

steps:
1. 從 http://sourceforge.net/projects/strace/files/strace/ 下載strace source code, 目前最新版為4.5.20 (strace-4.5.20.tar.bz2)
2. tar -jxv -f strace-4.5.20.tar.bz2
3. ./configure --host=arm-linux CC=arm-linux-gcc LD=arm-linux-ld   ,  配置makefile
4. make CFLAGS="-static"   , 產生靜態可執行檔
5. (可做可不做) arm-linux-strip strace  ,  縮減strace的size
完成, 之後就可以把strace copy到ARM 的 linux平台上執行了

uImage & zImage 差異
kernel 編譯完會產生 zImage。
uImage 是 zImage 在加上一個 64 Bytes 的 header。這是給 uboot 載入 kernel 用的。（利用 bootm ）
uImage 如何產生？ 利用 mkimage 來產生。
mkimage 參數說明：
[root@localhost tools]# ./mkimage
Usage: ./mkimage -l image
          -l ==> list image header information
       ./mkimage [-x] -A arch -O os -T type -C comp -a addr -e ep -n name -d data_file[:data_file...] image
          -A ==> set architecture to 'arch'
          -O ==> set operating system to 'os'
          -T ==> set image type to 'type'
          -C ==> set compression type 'comp'
          -a ==> set load address to 'addr' (hex)
          -e ==> set entry point to 'ep' (hex)
          -n ==> set image name to 'name'
          -d ==> use image data from 'datafile'
          -x ==> set XIP (execute in place)
-C 指定映像壓縮模式，可以取以下值︰none 不壓縮，gzip 用gzip的壓縮模式，bzip2 用bzip2的壓縮模式
-a 指定映像在記憶體中的載入位址，映像載入到記憶體當中時，要按照用mkimage製作映像時，這個參數所指定的位址值來載入到記憶體
-e 指定映像執行的入口點(entry point)位址，這個位址就是-a參數指定的值加上0x40（因為前面有個mkimage添加的0x40個位元組的表頭）
-n 指定映像檔案名稱
-d 指定製作映像的來源檔案名稱

SA_RESTART
Provide behavior compatible with BSD signal semantics by making certain system calls restartable across signals.
1, 訊號將中斷慢阻塞调用, 导致这些调用返回-1并且errno=EINTR表示被信号中断.
2, 部分函数是自启动的, 即永远不会返回-1与errno=EINTR, 它们在信号函数处理返回后继续执行完成, 而不是以彻底的失败告终.

Cross Compiler

從工作以來就一直使用Cross Compiler
可是現在終於知道為何這樣稱呼
我試著用口語來解釋
當我們使用compiler來編譯某個程式
該程式一定只能執行在與你編譯的機器相同的平台
但是現在Cross Compiler編譯出來的不是相同平台
而是要執行在你的target平台上，例如ARM
所以Cross Compiler for ARM就是編譯出來的程式
得由ARM CPU才能執行
那為什麼要這麼做呢
由於Compiler是很大的程式
需要快速運算以及較多的資源
如果由比較慢的原生平台(如ARM)來編譯
那程式設計師不就要常常打瞌睡了
讓快速的x86 PC來擔任編譯ARM程式 會較有效率
 
預設的include path可以透過 arm-linux-cpp -v 來取得
而library path 是由 arm-linux-gcc -print-search-dirs 取得
 
LIBRARY_PATH和LD_LIBRARY_PATH环境变量的区别



 

碰到过，是因为man和头文件不一致（可能是版本导致也可能就是mistake），
最后结果当然以实际的头文件为准。

引言：
Embedded Linux技術基於開放原始碼的資源，並且已經是當今最重要的嵌入式應用技術之一。Embedded Linux是燒錄在目標裝置上(特定硬體)的系統，1個Embedded Linux系統包含Linux kernel(核心)與 root filesystem(檔案系統) 2大部分，Embedded Linux系統到底由哪些組成要素構成，本文將由概念的層面進行分析。
本文：
由於目前的目標裝置(特定硬體)，都必須嵌入極為複雜的功能，所以「嵌入式作業系統(Embedded system)」成為嵌入式系統不可或缺的要素。由於嵌入式系統是功能導向的系統，因此必須設計、選擇或購買正確(或適合)的目標裝置，才能開始實作並嵌入「嵌入式系統」。因此，嵌入式系統技術是以功能、與目標裝置為分類的1種技術。
例如，與PDA相關的目標裝置(即硬體)、與MP3播放器相關的目標裝置、與3G手機相關的目標裝置...等等；使用這些目標裝置所開發的特定功能系統，便是PDA的嵌入式系統、MP3音樂播放的嵌入式系統、3G手機的嵌入式系統。
Embedded Linux其實並不是1個作業系統，而是代表「應用Linux系統於Embedded system」的名詞。Embedded Linux的技術核心主軸是在研究「如何將Linux系統嵌入至嵌入式目標裝置裡」。
Embedded Linux是基於Linux系統的特殊應用，當然也要符合眾多標準才行。LSB與FHS標準是重要的2大標準，跟隨標準不但可以提供系統間的相容性，也可以提供我們1個Linux系統的建構依據。
※GNU/Linux的2個標準
由 FSG (Free Standards Group) 所主持的 LSB (Linux Standard Base) 專案即是在制定 GNU/Linux 標準。根據LSB標準所發展的GNU/Linux系統，才能提供應用程式最小的可執行環境，並且可在依循LSB標準的Linux distributions上執行無誤。例如，我們可以在符合LSB標準的Red Hat Linux上發展應用程式，只要自行發展的Embedded Linux系統符合LSB標準所訂定的規範，應用程式就可以順利移植到Embedded Linux上執行。
LSB標準提供我們發展Embedded Linux的依據，雖然Embedded Linux系統是最小化的Linux，但因為Embedded Linux是嵌入式系統的軟體平台，所以我們不能任意精簡Linux系統，在精簡的過程中仍要保留最基本的作業系統環境，而LSB的標準正是在制定這些基本的需求。
FHS全名為Filesystem Hierarchy Standard，是定義檔案與目錄標準的文件，FHS的標準，定義了目錄與檔案的擺放位置，而UNIX-like的系統則是根據這個標準，管理整個檔案結構。因此，不管是系統廠商、Linux/UNIX distribution發展者(developer)、應用程式作者、套件管理者、系統維護人員都應該要依照FHS的標準來管理UNIX系統的目錄與檔案。
Embedded Linux的特色是大量使用自由軟體、與開放原始碼軟體(FOSS- Free & Open Source Software)資源，「任何你想要的軟體，幾乎都能在網路上找到自由軟體」已經成為Embedded Linux技術的重要支柱。自由軟體資源包山包海，舉凡應用程式、系統工具、網路工具、程式庫、圖形介面、小型瀏覽器、程式發展工具...等等都能找得到。
※Busybox
Busybox是重要的Embedded Linux工具箱，這個工具箱提供基本的UNIX指令、系統程式(daemon)與開機程序(init process)。Busybox用來建造1個基本、最小化且可開機的Linux系統，由於Busybox裡的指令與工具都經過最小化處理，因此已經是目前主要應用在Embedded Linux實作上的開放原始碼專案了。
※Embedded Linux的組成
圖說：Embedded Linux整體架構。
Embedded Linux平台除了Linux kernel(核心)外，還包含共享程式庫(shared library)。shared libraries是Linux kernel的重要支援，並且也是Linux架構裡獨立的1層。在應用程式方面，許多現存的開放源碼專案都可以直接「移植」到ARM平台。但這裡所指的移植是對原始碼進行跨平台編譯(cross compile)，並不是BSP(board support package)的移植。
跨平台編譯
因為開放原始碼開發工具的特性，在應用程式級別的移植工具上，可以有1套比較系統化的方法，也有相關的工具與環境可以使用，目前最熱門的跨平台編譯環境為OpenEmbedded。開放源碼軟體採用GNU Autoconf與GNU Automake來撰寫編譯法則(Makefile)，因此實務上，要將應用程式移植到ARM平台，大部分案例只需要做跨平台編譯即可。要了解如何將原始碼移植到ARM平台，需要學會GNU Autoconf以及GNU Automake的使用。
※GNU Autoconf
Autoconf是m4巨集的擴充套件，可以用來自動設定軟體套件的原始碼。Autoconf會產生1個協助程式編譯的設定文稿執行檔(configuration script)，以方便編譯原始碼前進行系統檢查與設定，使用GNU Autoconf時，必須安裝GNU m4套件。
※GNU Automake
Automake是自動產生Makefile.in的工具，需配合Autoconf使用，以產生可以讓GNU Make自動編譯原始碼的”Makefile”檔案。
※GNU Make
GNU Make會根據“Makefile”來自動編譯程式，而編譯完成的程式為執行檔(binary program)。GNU Make的重要特點，是沒有特定程式語言限制，甚至可以應用在非程式語言編譯的環境中，例如：系統維護工作與套件安裝，因此GNU Make可以說是系統自動化的好工具。
GNU Make根據“Makefile”檔案裡所定義的規則，執行Unix命令，簡單的Makefile，可以利用編輯器手動撰寫，但較複雜且與針對不同平台的設定，則建議採用GNU Autoconf/GNU Automake來產生“Makefile”。當我們能夠產生使用cross toolchain的Makefile時，就可以將套件編譯成ARM平台能夠使用的執行檔(binary program)。
※ARM 平台的選擇與支援
嵌入式裝置的硬體選擇當然沒有所謂的標準，但若是談論到嵌入式Linux的應用，在平台的選擇上就會有一些考慮。最重要的考慮因素，當然就是處理器對於作業系統的支援，如此一來，沒有MMU(記憶體管理單元)的ARM7平台，就不在主要的選擇範圍內。以下列出幾個目前普遍使用的ARM9應用程式處理器(application processor)：
在選擇解決方案時，若是決定採用Linux做為嵌入式作業系統，首先當然就是要確定廠商是否提供完整的BSP(Board support package)。不過，由於Linux是由社群(community)所維護發展，因此，選擇目前Linux kernel內有支援的平台，將會是較好的選擇，這也是為什麼有許多大廠，主動貢獻並提交BSP給kernel.org的原因。
目前在Linux kernel(核心)社群比較活躍的ARM9廠商，或是社群主動積極協助維護的SOC平台，像是ATMEL、Samsung與TI OMAP等，這些都是kernel.org的Linux kernel就有支援的處理器，這表示讓Linux支援這些平台的方式也很簡單，就是到kernel.org下載官方的Linux kernel即可。
※Cross Toolchain(跨平台編譯工具鏈)
針對ARM9或是其它平台的開發，最重要的工具就是Cross Toolchain。Cross Toolchain的製作一直是Embedded Linux開發者的夢靨，大多數人選擇由網路下載現成的開發工具，但經常會遇到缺乏程式庫的編譯錯誤。完整的Cross Toolchain包含1套基本的gcc cross compiler以及其它的應用程式庫；Cross Toolchain是製作基本gcc cross compiler的工具，透過crosstool即可製作ARM9的基本toolchain。
Root Filesystem(根檔案系統)概念
Root filesystem的建置，即是在建立1個基本的Linux系統(base system)，讓kernel在完成開機後，進入user mode執行使用者程式。Root filesystem的建置主要是以Busybox為主，並加入(移植)客製化的開放源碼(open source)與自由軟體(free software)。
因為嵌入式Linux的root filesystem是依照需求加入套件，與桌面環境的Linux distribution不同，因此都是用從頭打造的方式做起。在建立root filesystem時，程式庫相依 (library dependencies) 的議題是相當重要的項目。當root filesystem缺少必要的library時，程式當然無法執行，甚至系統也會無法順利啟動。分析應用程式所需的相依程式庫，觀念如下：
(1)先利用Cross Toolchain的objdump指令觀察ELF格式裡的「NEEDED」項目。
(2)必須再檢查這些library是否相依其它library。
1個基本且可開機的root filesystem，也稱做bootstrap root filesystem，1個可用的bootstrap root filesystem只需要包含busybox與libc即可。傳統的Embedded Linux應用，大多是以NFS掛載的方式來測試目標裝置的完整root filesystem(full root filesystem)。以NFS進行Embedded Linux開發測試，主要是針對目標裝置的full root filesystem做「立即(right now)」的系統執行測試(run-time)，免除「不斷打包image file、開機」的惡夢。這是1種流行很久的Embedded Linux系統測試與開發方式，其概念如下：
(1)將target的完整root filesystem(例如ARM9 root filesystem)建置後，存放於host端的某個目錄下，例如/home/rootfs。
(2)為target製作1個「NFS root filesystem」，也就是bootstrap root filesystem＋ NFS功能，並使用NFS root filesystem將目標裝置開機。
(3)設定host端為NFS server。
(4)以NFS mount方式將host端上的root filesystem目錄「mount」到目標裝置，即可在目標裝置上執行full root filesystem裡的應用程式。
這種方式不但簡單，而且方便，需要的基礎建設如下：
1.目標裝置使用的kernel必須支援NFS檔案系統。
2.製作bootstrap root filesystem時，需要加入mount指令，並且開啟mount指令的NFS功能。
3.加入NFS functionality至bootstrap root filesystem。
4.設定NFS server。
製作完成的root filesystem必須做打包的動作，將整個root filesystem包裝成1個映像檔(image file)。根據目標裝置的不同，我們可以將映像檔包裝成ROM filesystem、Compress ROM filesystem、ext2 filesystem或是compress RAM filesystem。
※ROM file system
ROM file system(romfs)是1種唯讀(Read-Only)的檔案系統，在Embedded Linux裡的主要應用為製作rom fs格式的檔案系統映像檔。我們將root filesystem製作成romfs filesystem的image檔。開機後，整個filesystem僅能讀取。要使用romfs filesystem必須將Linux kernel裡的CONFIG_ROMFS_FS功能選項打開。製作ROM fs映像檔所使用的工具為genromfs。
※Compressed ROM file system
Compressed ROM file system(crom fs)即是壓縮過的ROM file system，其製作方式相當簡單，只要使用gzip將ROM file system的映像檔壓縮即可。
※製作ext2fs映像檔
製作ext2fs映像檔的方式有2種。1種是使用dd指令產生1個空白的映像檔，接著再將此映像檔以mkfs.ext2指令格式化成ext2的格式。製作好的空白映像檔再以loopback mount方式掛載到1個目錄下，再將root filesystem整個複製到此目錄下，即可完成ext2fs映像檔的製作。
另外1種建立ext2fs映像檔的方式是使用genext2fs工具，此工具的好處是，當我們需要在root filesystem裡預先建立(pre-built)裝置檔時(device file)，只需要編寫1個裝置檔表格，genext2fs工具會在打包映像檔時，自動在root filesystem裡建立裝置檔。
※Initial RAM disk(initrd)
RAM disk是存在於記憶體中的虛擬磁碟，也就是將RAM拿來當成磁碟使用。在Embedded Linux的應用中，我們通常會將ramdisk當成暫存目錄來使用。例如將/dev/ram1附掛到/tmp目錄，以便能讓應用程式存放暫時性檔案。/dev/ram?為ramdisk的device file。由於整個root filesystem是從真正的儲存裝置讀取並載入至ramdisk，因此有1個重要的特性是對file system所做的任何修改，都不會影響到真正root filesystem的內容。
initrd全名為initialize RAM disk，是1個特殊的RAM disk。bootloader會將initrd載至記憶體，Linux kernel則可在/dev/ram0找到initrd。initrd會在Linux kernel開機前就載入，initrd正式的用途是用來存放開機時所需要的驅動程式(因root filesystem尚未mount進來)。在Embedded Linux應用上，我們會利用initrd來存放整個檔案系統(root filesystem)，也就是將root filesystem製作成ext2或romfs格式(或其它檔案系統)的映像檔，並在開機時由bootloader載入記憶體，initrd均位於/dev/ram0。要使用RAM disk與initrd，必須將Linux kernel的CONFIG_BLK_DEV_RAM以及CONFIG_BLK_DEV_INITRD)打開。
※使用initrd做為root filesystem裝置
將initial RAM disk當成root filesystem來使用，是在Embedded Linux應用上是相當常見的技巧，如果我們想將initial RAM disk當成存放root filesystem的裝置來使用，在開機時，只需要配合「root=」的kernel開機參數即可。
※initramfs
Linus本人在Linux 2.6時代所提出的 "initramfs" ，是1種更好的 "root=" 做法。簡單來說，initramfs就是「kernel 2.6 的 initrd」，initramfs是屬於1種compressed ramfs(ram filesystem)的映像檔。
※C程式庫
在C程式庫方面，除了標準的glibc也被廣泛應用在嵌入式系統領域外，也有一些專門針對嵌入式系統應用所發展的C程式庫，像是uClibc以及Diet libc。但是由於現在的ARM9處理器計算效能都很快，平台也多搭載大容量NAND快閃記憶體(NAND Flash)，所以許多實作都直接使用libc來實作root filesystem。
Linux驅動程式
由於嵌入式系統整體來看，除了軟體開發外，也包含硬體客制化，因此驅動程式在嵌入式系統技術領域中，佔了舉足輕重的地位。學習驅動程式需要確實瞭解硬體的規格與微處理器架構，並且工程師還要能分得清楚哪些東西是介面(interface)，也就是與硬體無關的程式(machine-independent)；以及哪些是站在第一線做硬體控制的程式(machine-dependent)。各種軟體硬介面與?流排也都要精通。
了解Linux驅動程式的架構，是進入嵌入式Linux領域的重點功課，因為許多針對ARM9平台的驅動程式都是參考框架、或是針對特定開發板的實作，因此必須了解Linux驅動程式的架構，並進行修改，以符合自己的開發板與週邊規格。
Linux驅動程式，採取嚴謹的分層式架構設計(layered architecture)，利用分層的架構設計來徹底區分generic device driver(machine independent)與machine dependent driver。
Linux驅動程式透過「註冊」與「回呼」的機制來清楚區分每1層的關係。分層架構的實作必須在下層將自己註冊給上層，上層再回呼下層；上層的驅動程式必須提供註冊函數供下層呼叫，下層驅動程式所使用的註冊函數也將決定自己的上層架構。
與user application如何互動，是撰寫驅動程式時所要考慮的重要一環，因此撰寫驅動程式時，要提供什麼「功能」給應用程式引用，就必須事先定義清楚。Linux的 generic device driver層已經幫我們把這些功能定義清楚了。Linux驅動程式如何透過I/O port或I/O memory來控制裝置，也就是與晶片組的溝通，方式是使用Linux kernel所提供的I/O函數來存取並控制實體硬體裝置。
※Linux驅動程式的裝置檔
Device files是UNIX系統的獨特觀念，在UNIX系統底下我們把外部的周邊裝置均視為1個檔案，並透過此檔案與實體硬體溝通，這樣的檔案就叫做device files或special files。
Device file的major number代表1個特定的裝置，例如major number 1為”null”虛擬裝置，major number定義於kernel文件目錄Documentation/devices.txt。Minor number代表裝置上的子裝置，例如同1個硬碟上的分割區就用不同的minor number來代表，但其major number相同。
我們在設計device driver時，會先透過1個“註冊”(register)的動作，將自己註冊到kernel裡，註冊時，我們會指定1個major number參數，以指定此驅動程式所要實作的週邊裝置。當user開啟device file時，kernel便會根據device file的 major number找到對應的驅動程式回應使用者。Minor number則是device driver內部所使用，kernel並不會處理不同的minor number。
※Linux 2.6的kobject模型
Linux 2.6在驅動程式的架構方面，加入kobject的概念。kobject以更有系統、組織的方式維護系統裡的driver(集中式管理)，但並非改變現有(kernel 2.4以來)的driver架構。在kobject的模型下，可以看到1個platform driver觀念。所謂「platform driver」就是machine- dependent driver，當驅動程式設計師在kernel 2.6底下實作machine-dependent driver時，就要以platform driver的架構來實作。例如，針對我們的目標裝置進行硬體層的驅動程式撰寫時，就要以platform driver的方式來撰寫，實作上，只是多1個註冊到platform driver層的動作而已。
※Flash(快閃記憶體)裝置的支援
針對嵌入式系統經常使用的快閃記憶體(Flash)儲存裝置，Linux kernel支援JFFS2與NFTL 2個專門針對快閃記億體設計的檔案系統。JFFS2(Journaling Flash File System version 2)是專門針對 NOR 型快閃記憶體所設計的檔案系統。NFTL(NAND Flash Translation Layer)則是專門針對NAND型快閃記憶體設計的檔案系統。
結論
綜合而言，Embedded Linux是1個平台、也是一些工具的集合、也是1個嵌入式軟體的開發環境；實作上，Embedded Linux除了會進行kernel的修改、驅動程式的移植或開發外，也會是系統管理與系統整合的再應用，這是一門集大成的技術，並不只是1個嵌入式作業系統，也不只是1套開發工具。(本文為Jollen’s Consulting, Inc.技術顧問撰寫http://www.jollen.org/consulting)
參考來源
http://tech.digitimes.com.tw/ShowNews.aspx?zCatId=126&zNotesDocId=0000080936_B9WL69LZUF2L4FY7IZ4C5

劇情簡介：美國「世界科幻協會」雨果獎、「美國科幻暨奇幻作家協會」星雲獎雙料得主歐森史考特卡德暢銷科幻小說【戰爭遊戲】改編。蟲族曾兩度攻擊地球並幾乎摧毀人類，為了保障人類能在下一場戰爭中獲勝，聯合政府培育一群軍事天才，培訓他們的戰略技能，一開始的訓練，是以「遊戲」的方式展開……。安德是天才中的天才，他在每一場遊戲中都獲得勝利，但他是否有足夠的智慧去拯救這個星球？

---

劇情簡介：【蜘蛛人: 驚奇再起】續集。 對彼得派克(安德魯高菲 飾演)來說，得同時身兼除暴安良的蜘蛛人以及兼顧學校課業、與關史黛西(艾瑪史東 飾演)的感情等，把他生活壓得喘不過氣。不過高中畢業轉眼來到，彼得尚未忘記與關的父親的約定，斷絕與關的一切連絡，只是他從未辦到。隨著新的反派電人(傑米福克斯 飾演)出現，老友哈利(丹恩迪漢 飾演)回歸，彼得也發現了自己新的身世之謎。保羅賈麥提與克里斯庫柏將飾演反派犀牛人與綠惡魔。

---