本文章採用 Markdown 語法撰寫，若無法完整閱讀全文，請點擊這裡。

• 2017.10.23 UPDATE: The paper can be download at the LD-DL workshop website.

本文章採用 Markdown 語法撰寫，若無法完整閱讀全文，請點擊這裡。

本文章採用 Markdown 語法撰寫，若無法完整閱讀全文，請點擊這裡。

本文章採用 Markdown 語法撰寫，若無法完整閱讀全文，請點擊這裡。

本文章採用 Markdown 語法撰寫，若無法完整閱讀全文，請點擊這裡。

本文章採用 Markdown 語法撰寫，若無法完整閱讀全文，請點擊這裡。

本文章採用 Markdown 語法撰寫，若無法完整閱讀全文，請點擊這裡。

本文章採用 Markdown 語法撰寫，若無法完整閱讀全文，請點擊這裡。

本文章採用 Markdown 語法撰寫（why?），若無法完整閱讀全文，請點擊這裡。

本文章採用 Markdown 語法撰寫（why?），若無法完整閱讀全文，請點擊這裡。

本文章採用 Markdown 語法撰寫（why?），若無法完整閱讀全文，請點擊這裡。

本文章採用 Markdown 語法撰寫（why?），若無法完整閱讀全文，請點擊這裡。

本文章採用 Markdown 語法撰寫（why?），若無法完整閱讀全文，請點擊這裡。

Please follow this link if you are unable to read this article. ]]> https://www.jollen.org/blog/2016/01/build-coap-message-freertos-esp8266.html https://www.jollen.org/blog/2016/01/build-coap-message-freertos-esp8266.html IoT & WoT Wed, 27 Jan 2016 23:58:03 +0800 根據 2016 CES 的 IoT 產業新聞分析：WiFi Module 正以出乎意料外的速度，佔領 IoT 市場，並且 RTOS 與 HTML5 扮演重要的主流 IoT 技術。本文介紹如何使用 ESP8266 做為 FreeRTOS 的學習環境。

本文章採用 Markdown 語法撰寫（why?），若無法完整閱讀全文，請點擊這裡。

本文章採用 Markdown 語法撰寫（why?），若無法完整閱讀全文，請點擊這裡。

本文章採用 Markdown 語法撰寫（why?），若無法完整閱讀全文，請點擊這裡。

為了在 NodeMCU 上進行 WoT 實驗，日前開啟了一個小型的專案 node-wot，node-wot 將會持續小幅修改 nodemcu-firmware，以做為 WoT 的實驗用 firmware。

本文章採用 Markdown 語法撰寫（why?），若無法閱讀內文，請點擊這裡。

以下將說明 IoT 第 4 階段，也就是 WoT 最重要的一個觀念：使用 Websocket channel server 來封裝 IoT objects，讓 IoT devices 成為抽象化的 Websocket server。

關於 IoT 與 Websocket

一般來說，Websocket 的使用案例（use case）是 server push（data push）機制，也就是說，ARM mbed 物件本身，應該是扮演 Websocket server 的角色。但現實層面，讓 IoT 分演 Websocket server 的話，會有幾個技術問題：

1. ARM mbed 要管理 client 端的 connections
2. 需要更多的內存來維護 client connections
3. 需要實作 Data push 的演算法，例如：round-roubin
4. 要考量 error handling 與 exception handling

因此，最簡單的 scenario 設計如下：

1. 佈署專用的 Websocket channel server
2. ARM mbed 將 data 即時推送（push）到 Websocket channel server
3. 用戶（user）與 Websocket channel server 建立 Websocket connection
4. 用戶接收 Websocket channel server 的即時資料（經由 server push）

抽像上來看，ARM mbed 仍然是 server 端，而不是 client 端；真正的 client 端是用戶。

Websocket Channel Server

Websocket channel server 扮演封裝 IoT 物件的角色，對 Websocket server 來說，只要能定義好「channel」的結構，就能封裝數以萬計、千萬計的 IoT 物件。「抽像上來看，ARM mbed 仍然是 server 端」，就是這樣的觀念。

ARM mbed 官方就提供了 Websocket channel server 的服務：

ARM mbed 與 Websocket Client

了解上述觀念後，技術的實作就能區隔為二個部份：

1. Websocket channel server 服務，可使用 sockets.mbed.org
2. ARM mbed 的 Websocket client 實作

寫作文

參考資源

註：本文節錄自「Node.js & HTML5 開發思惟與入門學習」一書，並原文重現。

本章的目標，是提昇初學者的開發功力。經過前面 4 個章節的介紹，學習到許多基本觀念與技術。接下來，將從三個不同的層面，深化目前所學到的觀念與技術：

• JavaScript 語言
• Web Service 架構
• Node.js 觀念

本章先從 JavaScript 語言開始。JavaScript 最重要的觀念是 Closure，這可以說是 JavaScript 初學者的第 1 堂。Closure 與暱名函數有很緊密的關係，這要由 Lambda 的觀念開始講起。

Lambda

Lambda（λ）是一個希臘字母（Λ 是它的大寫字母），用來表示許多觀念：

• 物理學家用來表示波長的符號
• 數學家用來表示空字串的符號
• 電腦科學家用來表示暱名函數（Anonymous Function）的符號

Lambda 在電腦科學領域，用來表示暱名函數，目的是進行運算。為了尋找一個語法簡易的運算表示方式，電腦科學家會這麼做。

Step 1：取得一個具名的函數

例如一個加法函數：

sum(x) = x + 2

函數 sum() 是具名函數，利用 JavaScript 來實作的話，寫法如下：

function sum(x) {
     return x + 2;
}

Step 2：改寫為暱名函數

Lambda 希望可以找到一個能運算的表示方法，而且要簡單，去除掉函數名稱，就是一個方式。沒有具體名稱的函數，就稱為暱名函數（Anonymous Function）。如果表示暱名函數呢？上述範例，以 Lambda 來表示的話，只要改寫成：

λx.x + 2

用 JavaScript 來實作的話，要如何撰寫呢？方式如下：

(function(x) {
     return x + 2;
})();

這就是第 1 章介紹的 Closure 觀念，最後加上的一對括號，稱為立即函數，意思是立即執行此暱名函數的意思。立即函數，以物件導向的角度來看，也可以解釋為立即實例化。

Step 3：使用 var 來宣告暱名函數

JavaScript 的 var 關鍵字用來宣告變數，所以也可以把暱名函數做為運算子（Operator）來宣告變數。例如：

var lambda = (function(x) {
     return x + 2;
})();

變數 lambda 被指定（Assign）為一個暱名函數。從 JavaScript 語言的角度來看，Closure 用來封裝出 Module，所以 lambda 變數也可以解釋成「一個模組」。宣告一個暱名函數的變數時，可以不需要 Closure。也可以採用以下的寫法：

var lambda = function(x) {
     return x + 2;
};

事實上，這個寫法更為普遍。一些文章也把這種寫法，稱做 Function Expressions。

有一個重要的觀念要釐清，上述的寫法，正規的解釋方式是「宣告暱名函數的變數」，所以 lambda 是一個變數，不能解釋為函數。如果說 lambda 是一個函數宣告，觀念上就不對了。不能單就 JavaScript 語法的角度來做解釋。

以 JavaScript 來說，函數宣告的寫法為：

function lambda(x) {
     return x + 2;
};

這個時候，lambda 就是一個函數。那一種寫法比較好呢？理論上，採用暱名函數宣告的方式較佳，因為 JavaScript 本身是一種 Lambda 的程式語言。

Callback Function

Lambda 本質上是一種表示方法，用來表示 Input 與 Output。所以，要表示一個平方的運算的話，寫法如下：

λx.x*x

這個運算式，也可以做為另一個 Lambda 式子的 Input，請看以下的說明。

Step 1：撰寫第一個計算平方的 Lambda 表示式

做法如下：

λx.x*x

Step 2：把上述的式子做為另一個 Lambda 的輸入

有一個 f(x) = x + 2 的函數，用 Lambda 來表示的話，寫法如下：

(λx.x+2)

如果要把 Step 1 的結果，做當上面式子的 x（輸入），合併後的寫法為：

(λx.x*x)(λx.x+2)

讓我們來筆算看看：

• x = 3 時，λx.x*x 的 Output 為 9
• 9 做為 λx.x+2 的 Input，成為 9 + 2，Output 為 11
• 答案就是 11

(λx.x*x)(λx.x+2) 等價於 9 + 2。

Step 3：使用 JavaScript 來實作

怎麼把 (λx.x*x)(λx.x+2) 寫成程式碼呢？非常簡單，由於 Output 就是返回值，所以等於「讓暱名函數的返回值，當做另一個暱名函數的參數」。程式碼如下：

var lambda = function(x) { return x + 2 };
var result = lambda(function(x) { return x * x} (3) );

console.log("Result: " + result);

這個輸出的輸出結果為 11。這可不是在賣弄程式碼，而是實現出 (λx.x*x)(λx.x+2) 這個 Lambda 演算。以暱名函數來表示 Lambda 是很常見的做法，但其實反應出 JavaScript 語法上的不足。如果能有一個更簡易的語法，讓我們表示 Lambda，這段程式碼就會比較精簡。

所以，這很可能要從修改 JavaScript 語法的角度，來做強化。未來，新的 ECMAScript（JavaScript 的語法標準）或許可以讓我們這樣寫程式：

function(x) { return x + 2 }  // 複雜的寫法
x => x + 2                            // 希望可以有這種精簡的語法

再舉一個例子：

var result = (x => x * x) 3;  // 左結合寫法，輸入值 3 放在最右邊，最後 result 為 9

如果將 Lambda 做為函數的參數：

[1, 2, 3, 4, 5]
     .map(function(x) { return x * x });

未來或許能簡化為：

[1, 2, 3, 4, 5]
     .map(x => x * x);             // 希望可以有這種精簡的語法

在 ECMAScript 還沒有正式加入相關語法前，我們目前還是只能使用暱名函數的寫法。

使用 TypeScript

在深入了解 Lambda 的觀念後，就能知道根本之道在於「新的 JavaScript 語法」。目前有一些 Open Source 程式庫，就試著在解決這個問題。唯有透徹底了解 Lambda 的觀念，才能知道這些程式庫目地何在。

筆者推薦的解決方案是：TypeScript。這是一個由 Microsoft 所開發的工具，實際上是一個 Compiler。TypeScript 提供了擴充的 JavaScript 語法，可藉由 TypeScript 編譯為標準的 JavaScript 語法。

首先，必須先使用 npm 安裝 TypeScript 工具：

$ npm install -g typescript

接著，以 TypeScript 的語法撰寫 JavaScript 程式碼。TypeScript 的語法就是 JavaScript 語法，只是提供了許多好用的擴充語言，因此學習上並沒有障礙。以下是一個 TypeScript 範例：

var square = (x) => x * x
console.log(square(3));

將程式碼儲存為 l.ts 後，再利用 TypeScript 編譯：

$ tsc l.ts

編譯後可以得到 l.js 檔案，以下是 l.js 的內容：

var square = function (x) {
    return x * x;
};
console.log(square(3));

看到編譯後的程式碼後，馬上可以反應出這個觀念：TypeScript 提供一個簡單好用的 Lambda 語法。當然，TypeScript 的功能很豐富，這只是牛刀小試。

1287 sp<ISurface> SurfaceFlinger::createSurface(
1288         ISurfaceComposerClient::surface_data_t* params,
1289         const String8& name,
1290         const sp<Client>& client,
1291         DisplayID d, uint32_t w, uint32_t h, PixelFormat format,
1292         uint32_t flags)

0 1 qcom

1303     //LOGD("createSurface for pid %d (%d x %d)", pid, w, h);
1304     sp<Layer> normalLayer;
1305     switch (flags & eFXSurfaceMask) {
1306         case eFXSurfaceNormal:
1307             normalLayer = createNormalSurface(client, d, w, h, flags, format);
1308             layer = normalLayer;
1309             break;
1310         case eFXSurfaceBlur:
1311             // for now we treat Blur as Dim, until we can implement it
1312             // efficiently.
1313         case eFXSurfaceDim:                                                
1314             layer = createDimSurface(client, d, w, h, flags);
1315             break;
1316         case eFXSurfaceScreenshot:
1317             layer = createScreenshotSurface(client, d, w, h, flags);
1318             break;
1319     }

• 開放平臺為戰略的軟體研發結構？企業管理技術的一環。

• 繁華再見後，手機業經營者挑戰巨大。至少別再衝浪了。

document.querySelector(“#header”);

<div id="message"></div>
<script type="text/javascript">  
$("#message").createWebSocket();
</script>

• 以Closure模式將類別封閉，這與Static class有關係，在這裡先不做討論
• 使用選擇器模式，範例採用目前最流行的jQuery selector ”$”
• Read/Write Div Pattern

$(“div#news”).html(“<h2>News Today</h2>”);

(function($) {
$.fn.createWebSocket = function () {
  if ("WebSocket" in window)
  {
     alert("WebSocket is supported by your Browser!");
     var ws = new WebSocket("ws://<you-ip-adderess>:8888/start");
     ws.onopen = function()
     {
     };
     ws.onmessage = function (evt) 
     { 
     };
     ws.onclose = function()
     { 
     };
     ws.onerror = function()
     { 
     };
  }
  else
  {
     alert("WebSocket NOT supported by your Browser!");
  }
};

})($);

<!DOCTYPE html>
<head>
<script type='text/javascript' src="./jquery.min.js">
<script type='text/javascript' src="./jquery.websocket.js">
</head>
<body>
<div id="message"></div>
　
<script type="text/javascript">  
$("#message").createWebSocket();
</script>
</body>
</html>

struct led_module_t {
   struct hw_module_t parent;
};

宏達電(HTC)在2010年MWC推出HTC Desire時，獲得相當不錯的迴響，網路上紛紛以「最強的Android手機」來評價它。當時的三星，在Android手機領域，完全沒有任何建樹。即使是今年震撼MWC的華為(Huawei)，或是令人刮目相看的中興(ZTE)，當年推出的Android手機完全無法與HTC Desire抗衡。在硬體規格上落後HTC一大截。

HTC一向都是領先的硬體技術者，在2011 MWC推出Incredible S時，硬體技術仍舊領先業界；今年的MWC，繼續以HTC One X保持領先的硬體技術。HTC One系列更再加碼，以自有的ImageSense軟硬體技術，把手機照像功能再推上一層樓。仕橙部落特別將HTC過去三年來的MWC主打機，做了一個整理。

製表：仕橙部落

從這張表可以發現，HTC在2010年時，硬體技術可說是大幅領先同業，以華為來說，當年所推出的機種，應用處理器也只有528MHz，螢幕規格更差了一大截。到了2011年，HTC Incredible S仍舊領先競爭對手，不過差距已經縮小許多。

到了今年，大家從媒體的報導就可以看得出來，HTC One X已經沒有硬體技術的優勢了；除了ImageSense外，華為與中興都已經和HTC並駕齊驅。

製表：仕橙部落

這倒是給了我們一個警示。2010年到2012年，實質上只有二個整年；華為與中興從大幅落後，到現在迎頭趕上，只花了730天的時間。這說明了，如果2013 MWC還是主打硬體規格，競爭對手之間，已經沒有任何差異性了；就像 [HTC新機功能強大　仍缺”獨賣”價值] 提到的：

分析師指出，雖然HTC在這次大會中證實自己仍是手機硬體技術的領導品牌廠，但這並不足以成為強大的競爭優勢，因為這些門檻別人很快就會跨越追上。

筆者的看法很簡單，HTC已經不需要向誰證明它的硬體技術，或是製造能力了，專注思考「差異化的價值」，一定能做得非常不錯。如果不認真去思考什麼是差異化的價值，那可能完全想不透，為什麼Samsung Galaxy SII能獲得如此迅速又巨大的成功；這可不是因為AMOLED面板被斷貨，這麼簡單的原因。而且，用什麼作業系統，對HTC來說也不是很重要的事情，也不必去再乎Bada作業系統的潛在影響力。

我們知道，雲端應用目前有二大龍頭：Google與Facebook。Google老大哥的Gmail、相簿、位置服務等，儼然成為一項民生必須品。Facebook則是在社交網路(Social Networking)領域獨佔鰲頭。他們都是網路巨擎，也都是以平臺(Platform)的概念經營。平臺的概念是什麼？簡單說，就是提供開發者API服務。

平臺是一個很容易理解的概念，就像大家手上的手機，裡頭安裝了許多使用到Google以及Facebook API的App；這些App都會透過「雲端」，存取其服務。iPhone與Android手機裡的這些「雲端App」，所使用到的核心技術，就是HTML5。這代表著，只要HTML5的規格能開始推出草案(Draft)，並且手機上的HTML5瀏覽器技術更加成熟，手機行業將會展開一場HTML5大戰。HTML5大戰就是雲端運算的戰爭，這肯定是新一波的軟體革命。以HTML5技術，結合網路服務、開發App，並整合至手機，將成為顯學。

所以，筆者認為，Android版Chrome的到來，從產業的角度來看，肯定是一個重要指標，具有特別的意義。它將帶領HTML5往前衝刺。其實，Chrome很早就是HTML5的領頭羊了，例如：早在2010年，Google就宣佈以HTML5取代Google Gear技術，從這裡可見一斑。

我們可以這樣假設：有了Chrome，雲(Cloud Computing)就更容易放進裝置裡。正因為如此，所以Chrome的出現，有了HTML5大戰的煙焇味。Chrome將加速雲端應用走進手機App，所以手機不能只有硬體功能，硬體廠將面臨新的一波挑戰。

This ought to be the era of the software developer.

「這應該是軟體人的時代」

Every week sees a new event courting the lowly hacker. Here are a few recent examples from my day timer: The Android Dev Con, ARM Tech Con, Blackberry Dev Con, Ubuntu Dev Con…and the list goes on.

「每週，都有很多活動，想要拉攏軟體高手，像是 Android Dev Con、ARM Tech Con、Blackberry Dev Con、UBuntu Dev Con。」

Even Taiwan's notebook makers are hungry for all the low level software architects they can find—especially those who can help them customize Android kernels for their future smartphones and tablets.

So, software developers, today is your day to unite. You have nothing to lose but your shackles.

「所以，軟體人，今天是你們要團結的日子，你們沒有什麼包袱，只要解開你的桎梏」

intArraryAdd(JNIEnv *env, jobject obj, jintArray arr)
 {
     jint buf[10];
     jint i, sum = 0;
　
     (*env)->GetIntArrayRegion(env, arr, 0, 10, buf);
　
     for (i = 0; i < 10; i++) {
         sum += buf[i];
     }
     return sum;
 }

• 1. Permissive License
• 2. Weak Copyleft
• 3. Strong Copyleft

Message msg = Message.obtain();

Return a new Message instance from the global pool. Allows us to avoid allocating new objects in many cases. (--Android SDK Reference)

	public boolean onKeyDown(int keyCode, KeyEvent event) {
		...
		mHandler.sendMessage(Message.obtain()); // 可避免產生不必要的物件
		...
	}

• Activity.runOnUiThread(Runnable)
• View.post(Runnable)
• View.postDelayed(Runnable, long)

多項重要技術的推出，讓Honeycomb成為真正的平板電腦作業系統。

• Service Layer 屬於 Application Framework 層，提供 Application 存取硬體的「服務」。理論上，這些服務是以 instance 的形式存在。
• Hardware Abstraction Layer 介於 Application Framework 與 Driver Framework 之間，以抽象形式存取硬體。理論上，HAL 層的存在形式有三種 - library (module) / server / communication bus。
• Native Servier 屬於整個 Android 作業系統最底層。理論上，它應該在 HAL 層之下，也是 HAL 不會是我們想像中「隔絕 kernel 的最下層」，存在形式為 daemon。
• Driver Framework 屬於 kernel-space 層，也就是包含在 Linux kernel 裡，「非常 long-term 來看」也可以是其它 OS。理論上，Driver Framework 是以 instance 的形式存在。

public class MusicPlayerUI extends Activity implements OnClickListener {
    /** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
　
        Button playBtn = (Button) findViewById(R.id.playBtn);
        Button stopBtn = (Button) findViewById(R.id.playBtn);
　
        playBtn.setOnClickListener(this);
        stopBtn.setOnClickListener(this);
    }
　
	public void onClick(View v) {
		Access Audio Hardware and get it ready.
		Control Audio Hardware and start music.
	}
}

public class MusicPlayerUI extends Activity implements OnClickListener {
    /** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
　
        Button playBtn = (Button) findViewById(R.id.playBtn);
        Button stopBtn = (Button) findViewById(R.id.playBtn);
　
        playBtn.setOnClickListener(this);
        stopBtn.setOnClickListener(this);
    }
　
	public void onClick(View v) {
		// TODO Auto-generated method stub
		MediaPlayer p = MediaPlayer.create(this, R.raw.test);
		p.start();
	}
}

jollen@android:~/try/mokoid_elcair-20100511$ touch system/core/init/init.c
jollen@android:~/try/mokoid_elcair-20100511$ . build/envsetup.sh 
including vendor/aosp/vendorsetup.sh
jollen@android:~/try/mokoid_elcair-20100511$ m INIT_BOOTCHART=true PRODUCT-dma6410xp-eng -j 8
============================================
PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=2.1-update1
TARGET_PRODUCT=dma6410xp
TARGET_BUILD_VARIANT=eng
TARGET_SIMULATOR=
TARGET_BUILD_TYPE=release
TARGET_ARCH=arm
HOST_ARCH=x86
HOST_OS=linux
HOST_BUILD_TYPE=release
BUILD_ID=ECLAIR
============================================

$ adb shell 'echo 120 > /data/bootchart-start'
$ adb shell 'mkdir /data/bootchart'

linux@android:~/android/mokoid$ adb shell
# ls -l /data/bootchart
-rw-rw-rw- root     root          389 2010-07-28 11:06 header
-rw-r--r-- root     root            0 2010-07-28 11:06 kernel_pacct
-rwxr-xr-x root     root       589824 2010-07-28 11:08 proc_diskstats.log
-rwxr-xr-x root     root      2293760 2010-07-28 11:08 proc_ps.log
-rwxr-xr-x root     root       196608 2010-07-28 11:07 proc_stat.log
# 

linux@android:~/android/mokoid$ cd system/core/init/
linux@android:~/android/mokoid/system/core/init$ ./grab-bootchart.sh 
7 KB/s (389 bytes in 0.048s)
1439 KB/s (405771 bytes in 0.275s)
2014 KB/s (3861856 bytes in 1.872s)
1936 KB/s (979391 bytes in 0.493s)
look at bootchart.tgz

$ sudo apt-get install bootchart

$ java -jar /usr/share/bootchart/bootchart.jar /tmp/android-bootchart/bootchart.tgz
Parsing /tmp/android-bootchart/bootchart.tgz
Wrote image: ./bootchart.png

Rinascimento, FOSS or FLOSS (free/libre/open source software)

神權至上的時期，被稱為「黑暗時期」，在 14 世紀興起的「文藝復興」運動，打破這個現象。也就是說，黑暗時代，神權至上，可能有很多像是「魔法」的東西，或是很多霍格華茲魔法學校（註：哈利波特的學校）；文藝復興後，很多近代科學開始發展，生活在此時期後的人類，哈利波特稱之為麻瓜（Muggle，指沒有魔法的人）。

在 13 世紀晚期，義大利中產階段因為生活上的富足，開始尋求更優雅與時尚的生活，於是萠生「脫離神權」的想法。知名詩人「但丁（1265-1321）」的出現，被認為是義大利文藝復興時代的開始。於是，「個人主義」，也就是文藝復興運動的重要產物之一，開始發展。許多耳熟能詳的「大師」，也在文藝復興時期開始出現，例如：米開朗基羅（忍者龜）；天文學、物理學、數學、生物學等，高中時期最令我頭痛的近代科學，有了重要的發展。

用近代的網路現象來比喻，文藝復興運動很像是 Web 2.0。出現很多新現象，例如：個人主義的興起，每個人都可以自由創作，發表成果，這裡的「個人主義」指的是「好的」個人主義，例如：分享、討論、知識交換，而不是自私的這種個人主義。

文藝復興時期，經典創作「聖彼得大教堂」花了 120 年的時間建造，由多位大師共同創作而成，很像是 Web 2.0 時代的「共筆」或是「協作」。Linux kernel 是網際網路時代，社群協作的重要創作之一。今天我們使用的 Android 手機，都是運行於 Linux kernel 軟體之上。

聖彼得大教堂，肯定是背包客必定點名的景點，這是天主教最神聖的地方。聖彼得大教堂花了這麼久的時間才完工，當然不可能是由同一位建築師獨立完成，參與聖彼得大教堂設計的建築師有勃拉芒特、拉斐爾、米開朗基羅、小莎迦洛，這也是聖彼得大教堂的特色；現今，自由軟體界，稱重要且具代表性的 developer 為「大神」。感謝以上四位大神的共同協作，讓我們在 700 年後的今天，能親眼目睹這個偉大的建築，能欣賞到令人嘆為觀止的繪畫與雕刻。

文藝復興運動，就像 Internet/WWW 的出現，以及後來的 Web 2.0 與開放源碼運動（Open Source Movement）一樣，影響全人類的生活與文化發展。近年來，手機也從封閉走向開放，以及「個人創作手機軟體」的運動發展，相信只要再 1~2 年的時間，我們的生活與文化，都會產生很大的改變。

自由軟體，打破「軟體黑暗時期」；每個人都能在手機上創作內容，也將打破「手機黑暗時期」。軟體黑暗時期？據可靠資料，可能指微x時期。

註1：這句話來自於 Richard M. Stallman 大師，對於自由軟體的自由「Free」之 [解釋]。

/* * Copyright (C) 2010 The Mokoid Open Source Project * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ #define LOG_TAG "LED Stub" #include <stdlib.h> #include <string.h> #include <unistd.h> #include <assert.h> #include <jni.h> #include <mokoid/led.h> #include <cutils/properties.h> #define HAL_DEFAULT_VARIANT "default" static const char *variant_keys[] = { "ro.hardware", /* This goes first so that it can pick up a different file on the emulator. */ "ro.product.board", "ro.board.platform", "ro.arch" }; #define HAL_VARIANT_KEYS_COUNT (sizeof(variant_keys)/sizeof(variant_keys[0])) int main() { int i; int status; char prop[PATH_MAX]; status = -EINVAL; for (i = 0; (status != 0) && (i < HAL_VARIANT_KEYS_COUNT); i++) { if (property_get(variant_keys[i], prop, NULL) == 0) { continue; } printf("Your property is: %s = %s\n", variant_keys[i], prop); } return 0; }

• ro.hardware
• ro.product.board
• ro.board.platform
• ro.arch

$ svn co http://mokoid.googlecode.com/svn/trunk/ mokoid

$ cp frameworks/base/services/jni/com_android_server_BatteryService.cpp /tmp

$ cd <path-to-your-android-source>/
$ repo sync

$ cp /tmp/com_android_server_BatteryService.cpp frameworks/base/services/jni/com_android_server_BatteryService.cpp

$ make PRODUCT-dma6410xp-eng

$ mkimage -A arm -O linux -T ramdisk -C none -a 0x50800000 -n "ramdisk" -d ramdisk.img ramdisk-uboot.img

U-Boot 1.1.6 (Jan 21 2010 - 08:58:14) for SMDK6410                              
                                                                                
                                                                                
CPU:     S3C6410@666MHz                                                         
         Fclk = 666MHz, Hclk = 166MHz, Pclk = 83MHz, Serial = CLKUART (ASYNC Mo 
Board:   SMDK6410                                                               
DRAM:    128 MB                                                                 
Flash:   0 kB                                                                   
NAND:    128 MB                                                                 
In:      serial                                                                 
Out:     serial                                                                 
Err:     serial                                                                 
Initialise LCD with values                                                      
Hit any key to stop autoboot:  0                                                
SMDK6410 # run system                                                           
dm9000 i/o: 0x30000300, id: 0x90000a46                                          
MAC: 00:40:5c:26:0a:5b                                                          
could not establish link                                                        
TFTP from server 10.0.1.24; our IP address is 10.0.1.25                         
Filename 'system.img'.                                                          
Load address: 0x50008000                                                        
Loading: T ####################################
...
done                                                                            
Bytes transferred = 59174016 (386ec80 hex)                                      
                                                                                
NAND erase: device 0 offset 0xa00000, size 0x4300000                            
Erasing at 0x4ce0000 -- 100% complete.                                          
OK                                                                              
                                                                                
NAND write: device 0 offset 0xa00000, size 0x386ec80                            
                                                                                
Writing data at 0x40b8800 -- 100% complete.                                     
 59174016 bytes written: OK       
SMDK6410 # run ramdisk_uboot                                                    
dm9000 i/o: 0x30000300, id: 0x90000a46                                          
MAC: 00:40:5c:26:0a:5b                                                          
could not establish link                                                        
TFTP from server 10.0.1.24; our IP address is 10.0.1.25                         
Filename 'ramdisk-uboot.img'.                                                   
Load address: 0x50008000                                                        
Loading: ################################                                       
done                                                                            
Bytes transferred = 158894 (26cae hex)                                          
                                                                                
NAND erase: device 0 offset 0x900000, size 0x100000                             
Erasing at 0x9e0000 -- 100% complete.                                           
OK                                                                              
                                                                                
NAND write: device 0 offset 0x900000, size 0x100000                             
 1048576 bytes written: OK          

/*
 * Copyright (C) 2009 Mokoid Open Source Project
 * Copyright (C) 2009 Moko365 Inc
 * 
 * Author: Jollen Chen <jollen@jollen.org>
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
 
#define LOG_TAG "MokoidLedStub"
 
#include <hardware/hardware.h>
 
#include <fcntl.h>
#include <errno.h>
 
#include <cutils/log.h>
#include <cutils/atomic.h>
 
#include <mokoid/led.h>
 
/**
 * Definition of kernel-space driver.
 */
#define	LED_DEVICE	"/dev/led"
#define	LED_C608	1
#define	LED_C609	2
 
static int led_device_close(struct hw_device_t* device)
{
	struct led_control_device_t* ctx = (struct led_control_device_t*)device;
 
	if (ctx) {
		close(ctx->fd);
		free(ctx);
	}
	return 0;
}
 
static int led_on(struct led_control_device_t *dev, int32_t led)
{
	int fd;
 
	LOGI("LED Stub: set %d on.", led);
	fd = dev->fd;
 
	switch (led) {
		case LED_C608: 
			ioctl(fd, 1, &led);
			break;
		case LED_C609:
			ioctl(fd, 1, &led);
			break;
		default:
			return -1;
	}
 
	return 0;
}
 
static int led_off(struct led_control_device_t *dev, int32_t led)
{
	int fd;
 
	LOGI("LED Stub: set %d off.", led);
	fd = dev->fd;
 
	switch (led) {
		case LED_C608: 
			ioctl(fd, 2, &led);
			break;
		case LED_C609:
			ioctl(fd, 2, &led);
			break;
		default:
			return -1;
	}
 
	return 0;
}
 
static int led_device_open(const struct hw_module_t* module, const char* name,
        struct hw_device_t** device) 
{
	struct led_control_device_t *dev;
 
	dev = (struct led_control_device_t *)malloc(sizeof(*dev));
	memset(dev, 0, sizeof(*dev));
 
	dev->common.tag =  HARDWARE_DEVICE_TAG;
	dev->common.version = 0;
	dev->common.module = module;
	dev->common.close = led_device_close;
 
	dev->set_on = led_on;
	dev->set_off = led_off;
 
	*device = &dev->common;
 
	/*
         * Initialize Led hardware here.
         */
        dev->fd = open(LED_DEVICE, O_RDONLY);
	if (dev->fd < 0) 
	    dev->fd = 2;   /* Error Handler */
 
	led_off(dev, LED_C608);
	led_off(dev, LED_C609);
 
success:
	return 0;
}
 
static struct hw_module_methods_t led_module_methods = {
    open: led_device_open
};
 
const struct led_module_t HAL_MODULE_INFO_SYM = {
    common: {
        tag: HARDWARE_MODULE_TAG,
        version_major: 1,
        version_minor: 0,
        id: LED_HARDWARE_MODULE_ID,
        name: "Sample LED Stub",
        author: "The Mokoid Open Source Project",
        methods: &led_module_methods,
    }
 
    /* supporting APIs go here. */
};

/*
 * Copyright (C) 2009 Mokoid Open Source Project
 * Copyright (C) 2009 Moko365 Inc
 * 
 * Author: Jollen Chen <jollen@jollen.org>
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
 
#include <hardware/hardware.h>
 
#include <fcntl.h>
#include <errno.h>
 
#include <cutils/log.h>
#include <cutils/atomic.h>
 
/***************************************************************************/
 
struct led_module_t {
   struct hw_module_t common;
};
 
struct led_control_device_t {
   struct hw_device_t common;
 
   /* attributes */
   int fd;
 
   /* supporting control APIs go here */
   int (*set_on)(struct led_control_device_t *dev, int32_t led);
   int (*set_off)(struct led_control_device_t *dev, int32_t led);
};
 
/***************************************************************************/
 
struct led_control_context_t {
	struct led_control_device_t device;
};
 
#define LED_HARDWARE_MODULE_ID "led"

• led.c
• led.h

on <trigger>
   <command>
   <command>
   <command>

setprop <name> <value>

setprop ro.product.device dma6410xp

<?xml version="1.0" encoding="utf-8"?>
<permissions>
    <library name="com.mokoid.server"
            file="/system/framework/mokoid.jar"/>
</permissions>

• 2010.2.8: MOSP: Mokoid Project (Mokoid Open Source Project) 上線

    @Override
    public Object getSystemService(String name) {
        if (getBaseContext() == null) {
            throw new IllegalStateException(
                    "System services not available to Activities before onCreate()");
        }
　
        if (WINDOW_SERVICE.equals(name)) {
            return mWindowManager;
        } else if (SEARCH_SERVICE.equals(name)) {
            ensureSearchManager();
            return mSearchManager;
        }
        return super.getSystemService(name);
    }

public class mokoidActivity extends Activity {
    ...
    @Override
    public Object getSystemService(String name) {
　
        if (MOTOR_SERVICE.equals(name)) {
            MotorManager mMotorManager = new MotorManager();
            return mMotorManager;
        }
        return super.getSystemService(name);
    }	
	...
}

public class HelloWorld extends mokoidActivity {
}

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.mokoid.LedTest"
    android:sharedUserId="android.uid.system">

int svc_can_register(unsigned uid, uint16_t *name)
{
    unsigned n;
    　
    if ((uid == 0) || (uid == AID_SYSTEM))
        return 1;
　
    for (n = 0; n < sizeof(allowed) / sizeof(allowed[0]); n++)
        if ((uid == allowed[n].uid) && str16eq(name, allowed[n].name))
            return 1;
　
    return 0;
}
　
int do_add_service(struct binder_state *bs,
                   uint16_t *s, unsigned len,
                   void *ptr, unsigned uid)
{
    struct svcinfo *si;
//    LOGI("add_service('%s',%p) uid=%d\n", str8(s), ptr, uid);
　
    if (!ptr || (len == 0) || (len > 127))
        return -1;
　
    if (!svc_can_register(uid, s)) {
        LOGE("add_service('%s',%p) uid=%d - PERMISSION DENIED\n",
             str8(s), ptr, uid);
        return -1;
    }
    ...
}

• SystemServer & ServerThread
• Main Thread
• android.app.Activity 與 android.app.Service
• Android Process 模式
• ServiceManager 與 getSystemService API
• JNI & Native Method
• Blocking & Long Operations
• VMThread & Thread
• Zygote 與 Linux fork System Call

• Manager API
• Proxy Object
• Remote Object
• Remotable Object
• IInterface & IServiceManager

static struct hw_module_methods_t led_module_methods = {
    open: led_device_open
};
　
const struct led_module_t HAL_MODULE_INFO_SYM = {
    common: {
        tag: HARDWARE_MODULE_TAG,
        version_major: 1,
        version_minor: 0,
        id: LED_HARDWARE_MODULE_ID,
        name: "Simple LED module",
        author: "The Mokoid Open Source Project",
        methods: &led_module_methods,
    }
　
    /* supporting APIs go here */
};

• tag：須指定為 HARDWARE_MODULE_TAG
• id：指定為 HAL Stub 的 module ID，我們的範例為”LED”
• methods：struct hw_module_methods_t，為 HAL 所定義的「method」
• struct hw_module_methods_t 是由 HAL 定義的標準介面，目前的 AOSP（Android Open Source Project）實作裡包含一個”open”介面

#include <hardware/hardware.h>
   
#include <fcntl.h>
#include <errno.h>
   
#include <cutils/log.h>
#include <cutils/atomic.h>
   
/*****************************************************************************/
   
struct led_module_t {
   struct hw_module_t common;
};
   
struct led_control_device_t {
   struct hw_device_t common;
   /* supporting control APIs go here */
   int (*set_on)(struct led_control_device_t *dev, int32_t led);
   int (*set_off)(struct led_control_device_t *dev, int32_t led);
};
   
/*****************************************************************************/
   
#define LED_HARDWARE_MODULE_ID "led"

#include <hardware/hardware.h>

#define LED_HARDWARE_MODULE_ID "led"

struct led_module_t {
   struct hw_module_t common;
};

struct led_module_t {
   struct hw_module_t common;
   　
   /* Place attributes here. */
　
   /* Place methods here. */
};

• 採用Service架構方式
• 不採用Service架構方式

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    >
<Button
    android:layout_width="wrap_content" 
    android:layout_height="wrap_content" 
    android:text="small world"
    android:textSize="12sp"
    android:background="@drawable/arrow"
    />
<Button
    android:layout_width="wrap_content" 
    android:layout_height="wrap_content" 
    android:text="big world"
    android:textSize="24sp"
    android:background="@drawable/arrow"
    />
<Button
    android:layout_width="wrap_content" 
    android:layout_height="wrap_content" 
    android:text="super world"
    android:textSize="48sp"
    android:background="@drawable/arrow"
    />
</LinearLayout>

• 文字部份使用TextView元件
• 使用TextView的XML attribute來設定文字大小
• 使用TextView的XML attribute來設定一張背景圖
• 使用NinePatch圖片做為背景圖，如此一來背景圖就可以隨著文字大小縮放

package com.moko.hellointentwallaper;
　
import com.moko.hellointentwallaper.R;
　
import android.app.Activity;
import android.content.Intent;
import android.os.Bundle;
import android.view.View;
import android.widget.Button;
　
public class HelloIntentWallpaper extends Activity implements View.OnClickListener {
    /** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
        　
        Button button = (Button)findViewById(R.id.set_wallpaper);
        button.setOnClickListener(this);
    }
　
    public void onClick(View v) {
        Intent intent = new Intent(Intent.ACTION_SET_WALLPAPER);
        startActivity(Intent.createChooser(intent, "Select Wallpaper"));
    }
}

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    >
	<TextView  
	    android:layout_width="fill_parent" 
	    android:layout_height="wrap_content" 
	    android:text="@string/hello"
	    />
    <Button android:id="@+id/set_wallpaper"
        android:layout_width="wrap_content" android:layout_height="wrap_content" 
        android:text="@string/set_wallpaper">
        <requestFocus />
    </Button>
</LinearLayout>

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
      package="com.moko.hellointentdialer"
      android:versionCode="1"
      android:versionName="1.0">
    <application android:icon="@drawable/icon" android:label="@string/app_name">
        <activity android:name=".HelloIntentDialer"
                  android:label="@string/app_name">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>
    <uses-sdk android:minSdkVersion="3" />
    <uses-permission android:name="android.permission.CALL_PHONE" />
</manifest>>

• drawable-land/ - landscope 模式的圖檔
• drawable-port/ - portrait 模式的圖檔

338 KB/s (837376 bytes in 2.417s)
        pkg: /data/local/tmp/Launcher.apk
Success

• onUpdate(): 收到ACTION_APPWIDGET_UPDATE廣撥時，框架會callback此method
• onDelete(): 收到ACTION_APPWIDGET_DELETE廣撥時，框架會callback此method
• AppWidgetManager: 管理App Widget的類別

    public void onUpdate(Context context, AppWidgetManager appWidgetManager, int[] appWidgetIds) {
        final int N = appWidgetIds.length;
        for (int i=0; i<N; i++) {
            int appWidgetId = appWidgetIds[i];
            updateAppWidget(context, appWidgetManager, appWidgetId);
        }
    }

    static void updateAppWidget(Context context, AppWidgetManager appWidgetManager, int appWidgetId) {
    	CharSequence text;
    	      
    	text = "www.jollen.org";
    	        
        RemoteViews views = new RemoteViews(context.getPackageName(), R.layout.main);
        views.setTextViewText(R.id.appwidget_text, text);
        
        appWidgetManager.updateAppWidget(appWidgetId, views);
    }
}

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
      package="com.moko.hellowidget"
      android:versionCode="1"
      android:versionName="1.0">
    <application android:icon="@drawable/icon" android:label="@string/app_name">
        <receiver android:name=".HelloAppWidgetProvider">
            <meta-data android:name="android.appwidget.provider"
                    android:resource="@xml/appwidget_provider" />
            <intent-filter>
                <action android:name="android.appwidget.action.APPWIDGET_UPDATE" />
            </intent-filter>
        </receiver>
    </application>
    <uses-sdk android:minSdkVersion="3" />
</manifest>

• onUpdate()
• onDelete()

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    >
<TextView  
    android:layout_width="wrap_content" 
    android:layout_height="wrap_content" 
    android:id="@+id/appwidget_text"
    android:textColor="#ff000000"
    />
</LinearLayout>

• 長度(width)
• 高度(height)
• 更新頻率
• UI layout檔

<?xml version="1.0" encoding="utf-8"?>
   
<appwidget-provider xmlns:android="http://schemas.android.com/apk/res/android"
    android:minWidth="85dp"
    android:minHeight="30dp"
    android:updatePeriodMillis="3000"
    android:initialLayout="@layout/main"
    >
</appwidget-provider>

/* 範例：HelloAppWidget.java */
package com.moko.hellowidget;
  
import android.appwidget.AppWidgetManager;
import android.appwidget.AppWidgetProvider;
import android.content.Context;
import android.widget.RemoteViews;
  
public class HelloAppWidgetProvider extends AppWidgetProvider {
  
    public void onUpdate(Context context, AppWidgetManager appWidgetManager, int[] appWidgetIds) {
        final int N = appWidgetIds.length;
        for (int i=0; i<N; i++) {
            int appWidgetId = appWidgetIds[i];
            updateAppWidget(context, appWidgetManager, appWidgetId);
        }
    }
      
    public void onDeleted(Context context, int[] appWidgetIds) {
    }
  
    static void updateAppWidget(Context context, AppWidgetManager appWidgetManager,
            int appWidgetId) {
    	CharSequence text;
      	
    	text = "www.jollen.org";
      	
        RemoteViews views = new RemoteViews(context.getPackageName(), R.layout.main);
        views.setTextViewText(R.id.appwidget_text, text);
  
        appWidgetManager.updateAppWidget(appWidgetId, views);
    }
}

• res/xml/appwidget_provider.xml
• res/layout/main.xml
• src//HelloAppWidgetProvider.java
• AndroidManifest.xml

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <style name="myTheme">
    	<item name="android:windowNoTitle">true        
    </style> 
</resources>

標籤裡加上「theme」屬性：

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
      package="com.moko.hellotheme"
      android:versionCode="1"
      android:versionName="1.0.0">
    <application android:icon="@drawable/icon" android:label="@string/app_name"
    	android:theme="@style/myTheme">
        <activity android:name=".HelloTheme"
                  android:label="@string/app_name">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>
</manifest>

執行結果： 圖1: HelloTheme的執行結果 在這個範例裡，我們並沒有修改任何的程式碼，其原理是透過佈景設定的方法。定義佈景的方式與定義樣式（styles）相同，同樣是在styles.xml裡以<item>標籤來定義。 以下是使用HelloTheme的說明： 1. <item>的name屬性為android:windowNoTitle時，表示定義是否要顯示視窗標題，在此設定為true，表示不要有視窗標題 2. 在<application>標籤裡加上theme屬性，將佈景套用到應用程式 佈景除了能套用到應用程式外，也能套用到activity。如何套用佈景到activity呢？只要在<activity>裡加入theme屬性即可，做法與<application>相同。]]>

• 在Android專案裡以XML資源檔來定義「樣式」
• 一個Android專案可以定義多個樣式
• 讓widget套用其中一個樣式

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <style name="myText">
        <item name="android:textSize">18sp</item>
        <item name="android:textColor">#880</item>
    </style>
</resources>

<?xml version="1.0" encoding="utf-8"?>
 <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    >
 <TextView  
    android:layout_width="fill_parent" 
    android:layout_height="wrap_content" 
    android:text="Hello, this is HelloStyles."
    style="@style/myText"
    />
 </LinearLayout>

import android.view.View;
  
public class HelloClickListener extends Activity implements View.OnClickListener {
   ...
}

   public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
        
        Button button = (Button)findViewById(R.id.btn);
        button.setOnClickListener(this);
    }

   public void onClick(View v) {
        Toast.makeText(
                this,
                "Yes.",
                Toast.LENGTH_LONG).show();  
    }

package com.moko.helloclicklistener;
   
import android.app.Activity;
import android.os.Bundle;
import android.widget.Button;
import android.widget.Toast;
import android.view.View;
   
public class HelloClickListener extends Activity implements View.OnClickListener {
    /** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
        
        Button button = (Button)findViewById(R.id.btn);
        button.setOnClickListener(this);
    }
    
    public void onClick(View v) {
        Toast.makeText(
                this,
                "Yes.",
                Toast.LENGTH_LONG).show();  
    }
}

• View.OnLongClickListener: onLongClick()
• View.OnFocusChangeListener: onFocusChange()
• View.OnKeyListener: onKey()
• View.OnTouchListener: onTouch()
• View.OnCreateContextMenuListener: onCreateContextMenu()

14 /*
15
16 Goals and Theory of Operation
17
18 The primary goal of this feature is to reduce the kernel boot time,
19 by doing various independent hardware delays and discovery operations
20 decoupled and not strictly serialized.
21
22 More specifically, the asynchronous function call concept allows
23 certain operations (primarily during system boot) to happen
24 asynchronously, out of order, while these operations still
25 have their externally visible parts happen sequentially and in-order.
26 (not unlike how out-of-order CPUs retire their instructions in order)
27
28 Key to the asynchronous function call implementation is the concept of
29 a "sequence cookie" (which, although it has an abstracted type, can be
30 thought of as a monotonically incrementing number).
31
32 The async core will assign each scheduled event such a sequence cookie and
33 pass this to the called functions.
34
35 The asynchronously called function should before doing a globally visible
36 operation, such as registering device numbers, call the
37 async_synchronize_cookie() function and pass in its own cookie. The
38 async_synchronize_cookie() function will make sure that all asynchronous
39 operations that were scheduled prior to the operation corresponding with the
40 cookie have completed.
41
42 Subsystem/driver initialization code that scheduled asynchronous probe
43 functions, but which shares global resources with other drivers/subsystems
44 that do not use the asynchronous call feature, need to do a full
45 synchronization with the async_synchronize_full() function, before returning
46 from their init function. This is to maintain strict ordering between the
47 asynchronous and synchronous parts of the kernel.
48
49 */

public boolean onOptionsItemSelected(MenuItem item) {
    	int item_id = item.getItemId();
    	
    	switch (item_id){
    		case R.id.new_message: 
	    	        AlertDialog.Builder builder = new AlertDialog.Builder(this);
	    	        
	    	        builder.setMessage("Also post your message to Twitter?");
	    	        builder.setCancelable(false);
	    	        
	    	        builder.setPositiveButton("Yes", new DialogInterface.OnClickListener() {
	    	        	public void onClick(DialogInterface dialog, int id) {
	    	        	}
	    	        });
	    	        
	    	        builder.setNegativeButton("No", new DialogInterface.OnClickListener() {
	    	        	public void onClick(DialogInterface dialog, int id) {
	    	        	}
	    	        });   
	    	        
	    	        AlertDialog alert = builder.create();
	    	        alert.show();
    			break;
    		case R.id.quit: 
                Toast.makeText(
                        this,
                        "Going to quit.",
                        Toast.LENGTH_LONG).show();    			
    			break;
    		default: return false;
    	}
    	return true;
 }

builder.setPositiveButton("Yes", new DialogInterface.OnClickListener() {
	public void onClick(DialogInterface dialog, int id) {
		}
});

import android.widget.Toast;

這是一個很好用的類別，特別是在初步建立Android應用程式的控制或行為時，可以輔助我們進行初步的測試工作。

配合上述的選單範例，我們將onOptionsItemSelected()回呼函數實作修改如下：

    public boolean onOptionsItemSelected(MenuItem item) {
    	int item_id = item.getItemId();
    	
    	switch (item_id){
    		case R.id.new_message: 
                Toast.makeText(
                        this,
                        "Please enter your message."
                                + " Your message is at max 255 characters.",
                        Toast.LENGTH_LONG).show();
    			break;
    		case R.id.quit: 
                Toast.makeText(
                        this,
                        "Going to quit.",
                        Toast.LENGTH_LONG).show();    			
    			break;
    		default: return false;
    	}

此範例以Toast快顯訊息類別來顯示簡短訊息，以驗證上一個選單範例的功能是否正常。

1. 建立選單的XML檔

在Android專案的res/目錄下新增一個menu/子目錄，然後建立options_menu.xml文件。

圖1: 建立menu/目錄

圖2: 建立options_menu.xml文件

2. 以XML定義選單內容

在options_menu.xml檔案裡，定義我們想要的選單內容。以下是一個範例：

<menu xmlns:android="http://schemas.android.com/apk/res/android">
    <item android:id="@+id/new_message"
          android:title="New Message" />
    <item android:id="@+id/quit"
          android:title="Quit" />
</menu>

3. 將選單加入應用程式

要如何在應用程式啟動時加入我們定義好的選單呢？在onCreateOptionsMenu()事件裡以MenuInflater類別將定義好的選單加入應用程式：

public boolean onCreateOptionsMenu(Menu menu) {
    MenuInflater inflater = getMenuInflater();
    inflater.inflate(R.menu.options_menu, menu);
    return true;
}

在這個範例裡，我們使用到二個類別：Menu與MenuInflater，因此記得import這二個套件：

import android.view.Menu;
import android.view.MenuInflater;

按下手機上的Menu鍵後，出現我們所設計的選單，如圖3。

圖3: HelloMenu範例的選單畫面

最後一個問題是，當使用者觸壓選單上的選項時，Android應用程式要如何處理？方法是透過onOptionsItemSelected()事件：

    public boolean onOptionsItemSelected(MenuItem item) {
    	return true;
    }

當此事件被回呼時，Android框架傳入被觸壓的選項物件，其類別為MenuItem；請import此套件：

import android.view.MenuItem;

前述的教學提到，Android應用程式編譯時，會自動產生R類別，即描述UI的類別。我們所定義的選單UI也會被放到R類別裡，如下：

package com.moko.hellomenu;

public final class R {
    public static final class attr {
    }
    public static final class drawable {
        public static final int icon=0x7f020000;
    }
    public static final class id {
        public static final int new_message=0x7f060000;
        public static final int quit=0x7f060001;
    }
    public static final class layout {
        public static final int main=0x7f030000;
    }
    public static final class menu {
        public static final int options_menu=0x7f050000;
    }
    public static final class string {
        public static final int app_name=0x7f040001;
        public static final int hello=0x7f040000;
    }
}

以下是處理MenuItem的程式範例：

    public boolean onOptionsItemSelected(MenuItem item) {
    	int item_id = item.getItemId();
    	
    	switch (item_id){
    		case R.id.new_message: break;
    		case R.id.quit: break;
    		default: return false;
    	}
    	return true;
    }

呼叫MenuItem的getItemId()方法，可取得該選項的ID，如此一來便能得知使用者所觸壓的選項。

/* 範例檔名：HelloMenu.java */
package com.moko.hellomenu;

import android.app.Activity;
import android.os.Bundle;
import android.view.Menu;
import android.view.MenuInflater;
import android.view.MenuItem;

public class HelloMenu extends Activity {
    /** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
    }
    
    public boolean onCreateOptionsMenu(Menu menu) {
        MenuInflater inflater = getMenuInflater();
        inflater.inflate(R.menu.options_menu, menu);
        return true;
    }
    
    public boolean onOptionsItemSelected(MenuItem item) {
    	int item_id = item.getItemId();
    	
    	switch (item_id){
    		case R.id.new_message: break;
    		case R.id.quit: break;
    		default: return false;
    	}
    	return true;
    }
}

1. 簡報一份
2. Android 入門教學文件共11集
3. 範例程式4例

因為研討會是一天的演講活動，因此這些內容很適合新手做為「學習 Android 應用程式」的入門教材，大約只需要一天的時間，就能初步了解 Android 的開發工具使用，並了解 Android 的應用程式模式，故取名為「Android Day Package」，期望能提供一個「Android 新手一天入門」的教學套件。請不吝指教。

簡報的部份是受零組件雜誌邀請，進行一天的 Android 演講活動，所特別製作的簡報；範例則是參考 Android SDK 所撰寫的實例，範例是配搭簡報進行實例講解所使用的程式碼。[下載 Android Day Package] 後，可搭配以下共11份教學文件學習；以下的教學文件是為製作簡報時的筆記，特別整理成一份教學文件與大家分享。

課程主題

Android 教學

• 2009.01.19: Jollen 的 Android 教學,#11: AndroidManifest.xml 的用途是什麼？
• 2009.01.19: Jollen 的 Android 教學,#10: 如何檢查 Service 是否已啟動？使用 Android 除錯器
• 2009.01.12: Jollen 的 Android 教學,#9: 啟動 Service - startService()
• 2009.01.12: Jollen 的 Android 教學,#8: 沒有 UI 的 Service
• 2009.01.08: Jollen 的 Android 教學,#7: 如何讓文字並排顯示 - TableLayout
• 2009.01.05: Jollen 的 Android 教學,#6: WebView 體驗與 findViewByID
• 2009.01.04: Jollen 的 Android 教學,#5: 使用 View 的 XML 屬性
• 2009.01.04: Jollen 的 Android 教學,#4: 使用 XML 安排 UI
• 2008.12.29: Jollen 的 Android 教學,#3: 第一個 Android 專案
• 2008.12.29: Jollen 的 Android 教學,#2: “Hello Moko” - Activity 與 View 的關係
• 2008.12.29: Jollen 的Android 教學,#1: Android 應用程式模式

    <application android:icon="@drawable/icon" android:label="@string/app_name">
    ...
        <service android:name=".MokoService">
        ...
        </service>
    ...
    </application>

       <service android:name=".MokoService">
        	<intent-filter>
        		<action android:name="com.moko.hello.START_MUSIC" />
        		<category android:name="android.intent.category.DEFAULT" />
        	</intent-filter>
        </service>

	@Override
	public void onStart(Intent intent, int startId) {
		super.onStart(intent, startId);
	}

在 Package Explorer 視窗裡找到目前 Android 專案的資訊描述檔，檔名是 AndroidManifest.xml。這是一個用來描述 Android 應用程式「整體資訊」的檔案，每個 Android 應用程式專案都會有一個。在這裡修改 Androidmanifest.xml 的目的是為了「在我們的 Android 應用程式裡加入一個 Service 類別」，這樣才有辦法啟動 Service。修改後的內容如下，紅色的部份是新增的描述：。

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
      package="com.moko.hello"
      android:versionCode="1"
      android:versionName="1.0.0">
    <application android:icon="@drawable/icon" android:label="@string/app_name" android:debuggable="true">
        <activity android:name=".HelloMoko"
                  android:label="@string/app_name">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
        <service android:name=".MokoService">
            <intent-filter>
                <action android:name="com.moko.hello.START_MUSIC" />
                <category android:name="android.intent.category.DEFAULT" />
            </intent-filter>
        </service>
    </application>
</manifest>

這是什麼意思呢？我們留待後續再做說明。接著只需要再加上一行程式碼，就能啟動 MokoService 類別了。

回到 HelloM 類別，加入一行程式碼：

public class HelloMoko extends Activity {
   /** Called when the activity is first created. */
   @Override
   public void onCreate(Bundle savedInstanceState) {
       super.onCreate(savedInstanceState); 
       
       setContentView(R.layout.main);
       
       startService(new Intent ("com.moko.hello.START_MUSIC"));
   }
}

Activity 類別裡有一個 method 叫做 startService：

startService(Intent service)

呼叫 startService() 即可啟動一個 Service 類別，只是，startService() 的參數是一個「Intent」的型別，並不是所要啟動的類別名稱。「Intent」是一個很像「Event」的類別，後續我們再做比較精確的說明，在這裡，我們不如把 Intent 當成是 Event（事件）。

當程式送出 com.moko.hello.START_MUSIC 事件給 Android 時，Android 便去尋找能處理此事件的類別，然後啟動它。在這裡，能處理 com.moko.hello.START_MUSIC 事件的類別就是 MokoService，這個關係就是透過 AndroidManifest.xml 的設定實現的。

以下是利用 Eclipse 環境自動產生的類別 'MokoService'：

import android.app.Service;
import android.content.Intent;
import android.os.IBinder;

public class MokoService extends Service {

	@Override
	public IBinder onBind(Intent intent) {
		// TODO Auto-generated method stub
		return null;
	}

}

MokoService 類別繼承自 android.app.Service，幾個有關 Service 的重要觀念如下：

1. Service 物件以 separated process 的方式執行，這表示 Service 與 UI（Activity）並不在同一個 process 裡執行，而是個自在不同的 process 執行。

2. Android 應用程式是在 Activity 裡啟動與停止 Service。

3. 覆載（override）onStart() 方法（method）在 Service 被啟動時，執行我們想要的背景功能。

4. 覆載 onDestroy() 方法在 Service 被停止時，停止執行中的背景功能。

以下是一個加入 onStart 與 onDestroy 的 MokoService 實作：

import android.app.Service;
import android.content.Intent;
import android.os.IBinder;

public class MokoService extends Service {

	@Override
	public IBinder onBind(Intent intent) {
		// TODO Auto-generated method stub
		return null;
	}
	
	@Override
	public void onStart(Intent intent, int startId) {
		
	}
	
	@Override
	public void onDestroy() {
		
	}
}

圖1: 文字並排顯示

建立新的專案「HelloLayout」，並撰寫程式碼如下：

package com.moko.layout;

import com.moko.layout.R;

import android.app.Activity;
import android.os.Bundle;

public class HelloLayout extends Activity {
    /** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
    }
}

由於我們採用 XML layout 的做法，所以主程式不需要做什麼修改。本範例的重點應該是在 main.xml 檔案的編寫。

新的 Android 專案創建時，預設是使用 LinearLayout（線性排版）來安排 UI。現在，我們將使用 TableLayout 來取代 LinearLayout，以「表格」方式來安排 UI。TableLayout 讓我們可以將畫面切割成一張表格，如果我們可以設計一個二欄式（2 columns）的表格，就可以做出如圖1的顯示效果了。

以下是 main.xml 的內容：

<?xml version="1.0" encoding="utf-8"?>

<TableLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent">

	<TableRow>
		<TextView  
		    android:layout_width="fill_parent" 
		    android:layout_height="wrap_content" 
		    android:text="www.androidin.com"
		    android:padding="3dip"
		    android:autoLink="web" />
		<TextView  
		    android:layout_width="fill_parent" 
		    android:layout_height="wrap_content" 
		    android:text="www.google.com"
		    android:autoLink="web" />
	</TableRow>

</TableLayout>

android.widget.TableRow 是配合 TableRow 使用的一個類別，當我們在 TableLayout 裡安排一個 TableRow 時，在 TableRow「裡頭的所有 View」就會被安排在同一列（row）裡。以本範例來說，在第一列（row）裡有二個 TextView，所以這二行文字顯示時，就會呈現如圖1的效果。

為了避免文字擠在一起，因此我們在 TextView 裡加上了 padding 的屬性，如下：

第一個 TextView 的 padding 為 3dip，表示與旁邊的 View 必須空 3 個「間格」，這樣二個 TextView 才不會擠在一起。

接下來請依照以下步驟，建立我們的第二個 Android 應用程式「Hello Web」。

建立一個新的 Android 專案，如圖1。

並且撰寫 HelloWeb.java 程式如下：

package com.moko.web;

import android.app.Activity;
import android.os.Bundle;
import android.webkit.WebView;

import com.moko.web.R;

public class HelloWeb extends Activity {
    /** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
        
        final String mimetype = "text/html";
        final String encoding = "utf-8";
        
        WebView wv;
        
        wv = (WebView) findViewById(R.id.wv);
        wv.loadData("<img src=\"http://www.google.com.tw/intl/en_com/images/logo_plain.png\" />", mimetype, encoding);
    }
}

上述程式碼採用 XML layout 方式來安排 UI，因此接下來的工作就是編輯 XML layout 檔案。

編輯 main.xml 來規劃「Hello Web」的 UI 如下：

<?xml version="1.0" encoding="utf-8"?>

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"
    android:layout_width="fill_parent"
    android:layout_height="wrap_content"
    >
<WebView 
	android:layout_width="fill_parent" 
	android:layout_height="wrap_content" 
	android:id="@+id/wv" 
	/>
</LinearLayout>

在這裡我們定義了「WebView」標籤，並且指定「WebView」的 ID 為「wv」。透過指定「ID」屬性給 View 的方式，便能「讓 Android 應用程式在執行時期（run-time）找到指定的 View 物件」。

怎麼在執行時期，找到「XML layout」安排好的 View 呢？看到 HelloWeb.java 的程式片斷如下：

        final String mimetype = "text/html";
        final String encoding = "utf-8";
        
        WebView wv;
        
        wv = (WebView) findViewById(R.id.wv);
        wv.loadData("<img src=\"http://www.google.com.tw/intl/en_com/images/logo_plain.png\" />", mimetype, encoding);

呼叫 findViewByID() 方法，即可在執行時期「動態取得 View 物件」。當我們在 main.xml 裡加入 WebView 標籤，「存檔」後，R.java 資源索引檔也會跟著更新，我們可透過「R.id.wv」來索引到 WebView 物件。以下是 R.java 的內容：

package com.moko.web;

public final class R {
    public static final class attr {
    }
    public static final class drawable {
        public static final int icon=0x7f020000;
    }
    public static final class id {
        public static final int wv=0x7f050000;
    }
    public static final class layout {
        public static final int main=0x7f030000;
    }
    public static final class string {
        public static final int app_name=0x7f040001;
        public static final int hello=0x7f040000;
    }
}

取得 WebView 物件後，呼叫 WebView 的 loadData() 方法，將 HTML 內容載入到 WebView 物件裡，並顯示在 Activity 上。loadData() 的參數如下：

• 第一個參數：HTML 內容
• 第二個參數：MimeType 類型，指定為 text/html，即 HTML 類型文件
• 第三個參數：文字編碼方法，指定為 utf-8（Unicode）

Hello Web 範例程式所載入的 HTML 文件是一個 <IMG> 標籤，因此我們在視窗上所看到的內容就是一張圖檔，如下圖（使用真正的 Google Phone 做測試）。

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"    
    >
<TextView  
    android:layout_width="fill_parent" 
    android:layout_height="wrap_content" 
    android:text="Jollen's Blog - http://www.jollen.org/blog"
    android:autoLink="web"
    />
</LinearLayout>

Android 應用程式的 layout（UI 佈局）除了直接撰寫程式碼的方式外，也能使用 XML 檔案來做描述（XML-based Layout）。在 Android Development Kit 的「Package Explorer」視窗，點選「res -> layout」選擇 main.xml，可以看到 “Hello Moko” 應用程式的 XML layout 檔案，如圖1。

以下這段 XML 用來描述「TextView」物件的 layout：

<TextView  
    android:layout_width="fill_parent" 
    android:layout_height="wrap_content" 
    android:text="@string/hello"
    />

public class HelloMoko extends Activity {
    /** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        
        setContentView(R.layout.main);
	}
}

當 Activity 被建立後，我們呼叫 setContentView() 方法，將主要的 UI（R.layout.main）顯示在視窗上。R.layout.main 索引到一個 TextView 物件，此物件定義於 main.xml。將 R.layout.main 顯示在 Activity 視窗上，請記得修改程式碼，才能使用 XML-based layout。

我們順帶將 TextView 物件的 text 屬性修改如下：

<TextView  
    android:layout_width="fill_parent" 
    android:layout_height="wrap_content" 
    android:text="Hello TextView"
    />

[2008-12-29 16:51:29 - HelloMoko] ------------------------------
[2008-12-29 16:51:29 - HelloMoko] Android Launch!
[2008-12-29 16:51:29 - HelloMoko] adb is running normally.
[2008-12-29 16:51:29 - HelloMoko] Launching: com.moko.hello.HelloMoko
[2008-12-29 16:51:32 - HelloMoko] Uploading HelloMoko.apk onto device 'HT843GZ46367'
[2008-12-29 16:51:32 - HelloMoko] Installing HelloMoko.apk...
[2008-12-29 16:51:35 - HelloMoko] Success!
[2008-12-29 16:51:35 - HelloMoko] Starting activity com.moko.hello.HelloMoko on device 
[2008-12-29 16:51:36 - HelloMoko] ActivityManager: Starting: Intent { comp={com.moko.hello/com.moko.hello.HelloMoko} }

package com.moko.hello;

import android.app.Activity;
import android.os.Bundle;
import android.widget.TextView;

public class HelloMoko extends Activity {
   /** Called when the activity is first created. */
   @Override
   public void onCreate(Bundle savedInstanceState) {
       super.onCreate(savedInstanceState);

       TextView tv = new TextView(this);
       tv.setText("Hello Moko");
       setContentView(tv);
   }
}

這是在 Android SDK 文件裡的一段範例程式，類別 HelloAndroid 繼自 Activity。下圖是Activity的生命週期（lifecycle）。在「Jollen 的 Android 教學,#1」裡提到 Activity 負責建立視窗，根據 Activity lifecycle，當視窗建立時，onCreate 事件被觸發，所以我們在 onCreate 裡建立 View。

TextView 是 Android 的其中一個 View，故名思義，這是一個顯示文字的 View。最後，呼叫 Activity 的 method 'setContentView' 來將 UI 顯示於視窗上。

以下是一段正常的 open system call 實作：

int card_open(struct inode *inode, struct file *filp)
{
	return 0;
}

當 process 開啟 device file 後，因為 kernel-space 的 open system call 實作會直接 return，因此 CPU 會切換至前景（foreground）、 process 繼續往下執行。

第二段是不正確的 open system call 實作：

int card_open(struct inode *inode, struct file *filp)
{
	while (1);
	return 0;
}

當 process 開啟 device file 後，因為 CPU 切換至後景（background），但是在 OS 裡頭的 open system call 實作是一個無窮迴圈，OS 並沒有做 system call 的返回，因此 CPU 並不會切換到前景，所以，電腦感覺起來呈現「當機」狀態。

因為 CPU 的時間無法切換到前景，因此任何的 process 都無法執行，電腦當然沒有任何反應。這裡，可沒有所謂的「time slice」與「context switch」的觀念與動作。請同學思考：作業系統是對 process 做排程。

最後一段程式，我們加入了呼叫排程器的動作：

int card_open(struct inode *inode, struct file *filp)
{
	while (1)
		schedule();
	return 0;
}

schedule() 是排程器主函數，等於是主動呼叫 scheduler 做 re-scheduling。在這個情況下，雖然 OS 仍然沒有做 system call 返回，但因為我們以「手排」的方式做排程，因此 CPU 會換切到前景，前景程式就會被分配時間執行，因此，電腦仍然有反應。

唯一要注意的地方是，因為這一個 open system call 並沒有 return，所以原來的 process 並不會繼續往下執行。利用三段簡單的程式碼，對作業系統的排程觀念做了一次討論，對於建立「什麼是 scheduling」的觀念，是很有幫助的。

$ lsusb
Bus 007 Device 002: ID 04b4:1724 Cypress Semiconductor Corp. 
Bus 007 Device 001: ID 0000:0000  
Bus 003 Device 001: ID 0000:0000  
Bus 006 Device 001: ID 0000:0000  
Bus 005 Device 034: ID 1457:5117 
Bus 005 Device 001: ID 0000:0000  
Bus 004 Device 001: ID 0000:0000  
Bus 004 Device 004: ID 04d9:0499 Holtek Semiconductor, Inc. 
Bus 002 Device 001: ID 0000:0000  
Bus 001 Device 001: ID 0000:0000

$ ps ax|grep adb
20092 ?        S+     0:00 grep adb
21032 ?        Sl     0:00 adb fork-server server
$ sudo kill -9 21032

$ sudo ifconfig usb0 192.168.0.200

$ export ADBHOST=192.168.0.202

$ adb devices
* daemon not running. starting it now *
* daemon started successfully *
List of devices attached 
emulator-5554   device

$ adb install HelloMoko.apk

Neo FreeRunner 有二個 3 軸加速度感測器，當手機移動時，可以利用程式讀取每 一個軸的加速度值。讀取加速度感測器的方法是透過 Linux 的 input layer：

    /dev/input/event{2,3}

Process 透過這二個裝置檔讀取 input layer 的資料，kernel 會回傳一筆加速度感測器的資料給 process，該筆資料的 data type 為 struct input_event，即 kernel 的 input event 資料結構。程式的做法是，每次讀取一筆加速度感測器資料，再判斷資料的類型，以及各軸的加速度值。

程式寫法如下：

    #include <linux/input.h>

    int main(void)
    {

        struct input_event motion;

        fd = open("/dev/input/event3", S_IRUSR);

        while (1) {
            read(fd, &motion, sizeof(motion));
        }
    }

struct input_event 資料結構的定義如下：

    struct input_event {
        struct timeval time;
        __u16 type;
        __u16 code;
        __s32 value;
    };

讀出的資料如下：

• motion.time: 讀取到該筆資料的時間
• motion.type: 值為 2 時，表示該筆資料為加速度值
• motion.code: 表示讀取的加速度方向，0 = x 軸、1 = y 軸、2 = z 軸
• motion.value: 該軸的加速度值，正負號代表「正負方向」

本範例讀取 FreeRunner 上的第二個 3 軸加速度感測器，x/y/z 軸所代表的方向如下圖。

如果想要讀取 x 軸的加速度：

    int x;

    /* 資料有效且為 x 軸 */
    if (motion.type == 2 && motion.code == 0) {
        x = motion.value;
    }

若 x 為負值，表示手機往左邊的方向移動。再舉一個例子，讀取 y 軸的加速度：

    int y;

    /* 資料有效且為 y 軸 */
    if (motion.type == 2 && motion.code == 1) {
        y = motion.value;
    }

若 y 軸的加速度為正值，表示手機往下移動。更多有關 FreeRunner 加速度感測器（accelerometer）的資訊，可參閱 Openmoko wiki [Accelerometer data retrieval]。

「專利權本身的目的是為鼓勵人們將新創概念公佈出來，但現行的專利體系卻會造成反效果，」

現今能做UI的技術很多，其中相對比較容易的方式就是以script language來打造UI，而當前最受注意的方式就是以Python快速寫UI。當然，網路上還有許多不同的UI技術，像是能讓「designer」真正自由發揮、免除寫code的SVG browser，也是一個值得注意的技術。

今天要介紹的主角是python-etk，故名思義，這是Python的ETK模組。ETK是一個不錯的東西，全名是Enlightenment Tool Kit，它的功能定位就像是GTK+的角色。GTK+是大名鼎鼎的圖形元件（widget）庫，由GTK+專案所沿伸出來的Glib也是一個使用廣泛的「強化版C程式庫」。ETK有沒有像Glib這樣的東西？有的，叫做Ecore。

Enlightenment（簡稱E）是一個知名且古老的window manager。[Enlightenment]包含許多程式庫以及工具，這些程式庫與工具總稱為EFL（Enlightenment Foundation Libraries）。簡單來看，可以畫出EFL的架構如下。

EVAS是一個「畫布」程式庫。Ecore的角色如同GTK+的產物Glib，不過並不完全等於。EDJE則是一個「layout engine」。最上面的ETK就是我們的主角，Enlightenment的圖形元件庫。

透過python-etk來實作ETK應用程式，可以帶給我們一些愉快的經驗。要怎麼寫一個向世界問好的入門級python-etk程式呢？以下是一個範例（hello_world.py）：

#!/usr/bin/python

import etk

class MyButton(etk.Button):
	def _size_request(self):
	    return (100, 200)

btn = MyButton(label = "Click Me")
btn.on_clicked(lambda x: etk.main_quit())

# Main
w = etk.Window(title="Hello World", size_request=(150, 150), child=btn)
w.show_all()

def quit(obj):
    etk.main_quit()
w.on_destroyed(quit)

etk.main()

目前有一些知名的Linux手機專案已經開始使用python-etk，例如Openmoko以及Nokia的maemo專案。後續將再配合一個範例來說明hello_world.py程式，及其執行結果。

We are pleased to announce that OpenedHand Ltd has been acquired by Intel Corporation. The OpenedHand team will join the Intel Open Source Technology Center and will focus on the development of the Moblin Software Platform, the optimized software stack for Intel Atom processors. Intel will continue supporting open source projects currently led by OpenedHand staff such as Clutter and Matchbox projects, and in most cases, will accelerate these projects as they become an integral part of Moblin.

$ gcc -o n_fork n_fork.c
$ ./n_fork &
This is the child process. PID: 8450
This is the child process. PID: 8451
This is the child process. PID: 8452
Parent process, PID: 8449
Child process ID: 8450 8451 8452

$ gcc -o helo helo.c
$ ./helo
0x80495c0
now x = 10
now x = 100

But unfortunately, people probably wont buy it...

but let us still cheer the OpenMoko team on for making a brave step forward.

#define TASK_RUNNING 0
#define TASK_INTERRUPTIBLE 1
#define TASK_UNINTERRUPTIBLE 2

set_current_state(state_value)

Raising Operator Confidence in Open Source, Guido Arnone, Director,Terminals Technology Vodafone * What is the benefit of Open Source for Operators? * What reservations are there about Open Source? * Understanding what the Operator wants to hear * Are Operators comfortable outside the walled garden?

The core Android system will be open source, but there’s no guarantee that carrier,s OEMs and application developers will keep their applications open source.

TOOL_TOP = /opt/crosstool/gcc-3.4.1-glibc-2.3.3/arm-9tdmi-linux-gnu
CC = $(TOOL_TOP)/bin/arm-9tdmi-linux-gnu-gcc
AR = $(TOOL_TOP)/bin/arm-9tdmi-linux-gnu-ar
LD = $(TOOL_TOP)/bin/arm-9tdmi-linux-gnu-ld
AS = $(TOOL_TOP)/bin/arm-9tdmi-linux-gnu-as
STRIP = $(TOOL_TOP)/bin/arm-9tdmi-linux-gnu-strip
RANLIB = $(TOOL_TOP)/bin/arm-9tdmi-linux-gnu-ranlib
TARGET_ARCH = arm-linux

THTTPD_CFLAGS = -Os -Wall -mtune=arm9tdmi -march=armv4 \
                -fomit-frame-pointer -fsigned-char -fPIC

configured-thttpd:
        (export CC=$(CC); \
        export AR="$(AR)"; \
        export AS=$(AS); \
        export LD=$(LD); \
        export STRIP=$(STRIP); \
        export RANLIB=$(RANLIB); \
        export CFLAGS="$(THTTPD_CFLAGS)"; \
        ./configure \
                --prefix=/ \
                --host=$(TARGET_ARCH) );

thttpd: configured-thttpd
        make

$ make -f thttpd.cross thttpd

"I am amazed at the depth of your commitment to open design. This must be the first time in history that a company has opened its intellectual property to this extent. Openmoko's revolutionary posting of the CAD files gives a whole new generation of Industrial Design students incredible insight into how it's done as well as an opportunity to contribute with new concepts."

int request_irq( unsigned int   irq,
                 void           (*handler)(int, void *, struct pt_regs *),
                 unsigned long  irqflags,
                 const char    *devname,
                 void          *dev_id);

JASA乃是日本社團法人嵌入式系統技術協會(Japan Embedded Systems Technology Association )的英文簡稱 。JASA成立於1986年8月7日，總部設在東京都中央區，分布則有札幌、東京、名古屋、金沢、大阪、福岡。目前會員數包括正會員: 148家企業 以及贊助會員:35家企業。

JASA主要的事業內容

日本最大的嵌入式技術展示會 ET SHOW (Embedded Technology） 每年11月在橫濱Pacafico Yokohama 舉行的日本業界嵌入式最大的展示會是由JASA所主辦的。而ET2007 也在2007年11月14 - 16日舉行完畢。

西日本地區唯一的嵌入式技術展示會 ETWest 西日本地區首屆以及第二屆的嵌入式系統技術展示會均於2006年和2007年在大阪Mydome Osaka會場舉行。不論是參展廠商及觀展人數均大幅超出大會預期，也顯示了西日本地區對於嵌入式系統技術的高度關心與注目。今年(2008年)西日本嵌入式系統技術展示會將移到大阪Intex Osaka會場舉行。展出日期為2008/6/5(Thu) - 6/6(Fri)。

嵌入式技術工程師認證制度「ETEC」(Embedded Technology Engineer Certification) JASA亦同時提供嵌入式技術工程師認證制度「ETEC」。這個認證制度主要目的在於「提供高教育的品質與標準化的技術範圍指標，同時希能促進嵌入式系統在業界的活躍度」。認證分為兩個等級，Class 2 初階 與 Class 1 中階，參加認證考試者將可得到JASA發行的證書。

ET軟體設計機器人比賽 (ET Robo ) ET軟體設計機器人比賽是以嵌入式軟體領域的技術教育為主題，且以樂高積木為車體，在既定走道上自動競速的一種比賽。並使用同一硬體(車體)，來進行UML等分析以及軟體設計的比賽。除了在夏季舉行的競技賽之外，在ET會期期間也會在展示會場內舉辦冠軍大賽。

與海外的嵌入式相關團體・企業之結盟提攜 JASA為促進提升與海外嵌入式業界的合作關係，除了邀請泰國，印度等海外嵌入式系統團體，前往當地廠商視察之外，也積極推動海外交流，因此在2006年11月15日JASA也與台北市電腦協會(TCA)締結MOU協定。

嵌入式系統技術教育相關 JASA也以嵌入式技術者的 Skill Standard(ETSS)為評量基準，建立培育嵌入式系統技術者(工程師)的基礎架構，並逐步進行Skill認定的實證實驗等相關準備階段。同時並網羅業界相關人士組成工作小組(WG)進行相關研究。

嵌入式技術者教育養成 JASA提供嵌入式技術的專門技術教育以及新人入門教育。期能在企業內訓之外，發揮補強機能。

要撰寫一支 user-space 的 USB device 控制程式，最首要的工作就是找到自己的 USB 裝置。這個工作主要透過以下 4 個函數來進行：

• usb_init: 初始化 libusb
• usb_find_busses: 尋找系統裡的所有 USB bus
• usb_find_devices: 尋找所有的 USB bus 上的所有 USB device
• usb_get_busses: 傳回找到的 USB bus

程式一開始必須先呼叫 usb_init 將 libusb 做初始化，這是 libusb 程式第一個要呼叫的函數。接著依序呼叫 usb_find_busses 與 usb_find_devices 找到所有的 USB bus 與 USB device。

最後，呼叫 usb_get_busses 取得所有找到的 USB bus。程式如下：

    usb_init();
    usb_find_busses();
    usb_find_devices();

    struct usb_bus *busses;
    busses = usb_get_busses();

*busses 指向一個串列資料結構（struct usb_bus），訪問這個串列即可找到所有的 USB 裝置。

接下來，我們要在所有的 USB bus 上偵測系統是否有我們的 USB device。以下是這段程式的框架：

    struct usb_bus *bus;
    for (bus = busses; bus; bus = bus->next) {
	    struct usb_device *dev;

	    for (dev = bus->devices; dev; dev = dev->next) {
               struct usb_device_descriptor *desc;

               desc = &(dev->descriptor);
               printf("Vendor/Product ID: %04x:%04x\n", desc->idVendor, desc->idProduct);
	    }
    }

這段演算法可以將系統上所有 USB device 的 vendor id 與 product id 印出來。假如，我們想找到特定的 USB 裝置，這時就可以設計一個這樣的函數（假設我們想要找的 USB 裝置是 0xffff/0x0001）：

struct usb_device *usbio_probe()
{
    struct usb_bus *busses, *bus;
    int c, i, a;

    usb_init();
    usb_find_busses();
    usb_find_devices();

    busses = usb_get_busses();

    for (bus = busses; bus; bus = bus->next) {
	struct usb_device *dev;

	for (dev = bus->devices; dev; dev = dev->next) {
	    struct usb_device_descriptor *desc;

	    desc = &(dev->descriptor);
	    printf("Vendor/Product ID: %04x:%04x\n", desc->idVendor,
		   desc->idProduct);
	    if ((desc->idVendor == 0xffff) && (desc->idProduct == 0x0001)) {
		return dev;
	    }
	}
    }

    return NULL;
}

找到我們的 USB device 後，接著就可以對它進行操作（讀/寫）。如同操作檔案般，我們要先對 USB device 做開啟的動作，方式是呼叫 usb_open 函數：

usb_dev_handle *usb_open(struct *usb_device dev);

開啟成功後，會傳回此裝置的 handle。

以下提供學習 libusb 的第一個範例程式：

/*
 * findusb.c - A libusb sample program.
 *
 *  Authored by Jollen Chen 
 *
 *  Copyright (C) 2008 www.jollen.org
 *  Copyright (C) 2008 Jollen's Consulting, Inc.
 *
 *  This program is free software; you can redistribute it and/or modify
 *  it under the terms of the GNU Public License as published by
 *  the Free Software Foundation; version 2 of the license.
 *
 *  This program is distributed in the hope that it will be useful,
 *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *  GNU Lesser Public License for more details.
 *
 */

#include <stdio.h>
#include <stdlib.h>
#include <usb.h>
#include <libusb.h>

void usbio_main(struct usb_device *dev)
{
    usb_dev_handle *dev_handle;

    dev_handle = usb_open(dev);

    if (dev_handle == NULL) {
	printf("USB IO open failed.\n");
	return;
    }

    usb_close(dev_handle);
}

struct usb_device *usbio_probe()
{
    struct usb_bus *busses, *bus;
    int c, i, a;

    usb_init();
    usb_find_busses();
    usb_find_devices();

    busses = usb_get_busses();

    for (bus = busses; bus; bus = bus->next) {
	struct usb_device *dev;

	for (dev = bus->devices; dev; dev = dev->next) {
	    struct usb_device_descriptor *desc;

	    desc = &(dev->descriptor);
	    printf("Vendor/Product ID: %04x:%04x\n", desc->idVendor,
		   desc->idProduct);
	    if ((desc->idVendor == 0xffff) && (desc->idProduct == 0x0001)) {
		return dev;
	    }
	}
    }

    return NULL;
}

int main()
{
    struct usb_device *dev;
    struct usb_device_descriptor *desc;

    dev = usbio_probe();
    desc = &(dev->descriptor);

    if (dev == NULL) {
	printf("USB IO Card not found.\n");
	return -1;
    }

    printf("SUB IO Card found.\n");
    printf("Vendor/Product ID: %04x:%04x\n", desc->idVendor,
	   desc->idProduct);

    usbio_main(dev);
}

檔案可由 [http://tw.jollen.org/findusb/] 下載。這裡提供一個 Makefile 檔案；編譯時，請記得安裝 libusb 並與 libusb 做連結。

* libusb API 文件. http://libusb.sourceforge.net/doc/

http://code.google.com/p/zhpy/

This wireless stack has many features, like a complete software MAC implementation, WEP, WPA, a "link-layer" bridging module, hostapd, QoS support to prioritize things like VoIP, 802.11g support, and full debug capabilities.

Another feature of this stack is a completely new user interface.

The disadvantage is the lack of drivers using this stack: the drivers that have been in the tree for a long time do not support this stack, and will need to be ported.

28 struct display_device;
29
30 /* This structure defines all the properties of a Display. */
31 struct display_driver {
32         int  (*set_contrast)(struct display_device *, unsigned int);
33         int  (*get_contrast)(struct display_device *);
34         void (*suspend)(struct display_device *, pm_message_t state);
35         void (*resume)(struct display_device *);
36         int  (*probe)(struct display_device *, void *);
37         int  (*remove)(struct display_device *);
38         int  max_contrast;
39 };
40
41 struct display_device {
42         struct module *owner;                   /* Owner module */
43         struct display_driver *driver;
44         struct device *parent;                  /* This is the parent */
45         struct device *dev;                     /* This is this display device */
46         struct mutex lock;
47         void *priv_data;
48         char type[16];
49         char *name;
50         int idx;
51 };
52
53 extern struct display_device *display_device_register(struct display_driver *driver,
54                                         struct device *dev, void *devdata);
55 extern void display_device_unregister(struct display_device *dev);

有時，老舊的程式碼，更容易幫助初學者掌握基本的架構與 API 用法。在 Linux 驅動程式的課程裡，我推薦同學研究一個早期的網路介面驅動程式，叫做 bonding.c。bonding 是一個用來合併網路卡的驅動程式，而早期的 bonding 驅動程式並沒有太多額外的 algorithm 實作，因此我建議同學，拿出 kernel 2.4.14 裡的 bonding.c 來做實例研究。由於這個版本的 bonding 驅動程式非常赤祼祼地呈現 register_netdev、struct net_device 與封包傳送的介面實作，因此肯定比許多最新的網路卡驅動程式更適合初學者。

kernel 2.4.14 的 bonding.c 可以在 2.6.x 的 kernel 上使用，美中不足的是，使用古老的 bonding driver 無法將 eth 介面合併進來，但至少可以配合 ifconfig 指令來做動態的操作與觀察，例如了解 'ifconfig bond0 down' 與 struct net_device::close 的實作。

如果要實際把玩 bonding 的功能，只要直接使用 kernel 2.6.x 本身的 bonding driver 即可。另外，kernel 2.4.14 的 bonding.c 必須修改一行 code，才能在 kernel 2.6.x 的環境下順利載入。以下提供此修改的 patch：

--- bonding.c.orig      2007-12-02 21:15:03.000000000 +0800
+++ bonding.c   2007-12-02 22:07:44.000000000 +0800
@@ -275,12 +275,11 @@
        /* Find a name for this unit */
        int err;
 
-       dev_bond.init = bond_init;
-
        err = dev_alloc_name(&dev_bond,"bond%d");
        if (err<0)
                return err;
 
+       bond_init(&dev_bond);
        SET_MODULE_OWNER(&dev_bond);
        if (register_netdev(&dev_bond) != 0)
                return -EIO;

為了與台灣的 open source 社群互動並回饋社群，OpenMoko 特別贊助成立了 OpenLab。OpenMoko 會不定時舉辦官方的 OpenLab 活動，第二次 OpenLab 活動將於 12/19 (三) 舉辦，本次活動除了延續上次的 Linux 驅動程式訓練外，更特別邀請了中研院自由軟體鑄造場法律組的林誠夏先生來為大家介紹 GPL 的法律觀念。 另外，這次的活動也特別針對 Apache 授權的觀念進行隨興討論，現場由主持人針對 Apache 授權做介紹，並與現場朋友做討論與收集意見回饋。Google 的 Android 手機平臺採用的是 Apache 授權，與 OpenMoko 的 GPL/LGPL 授權不同，我們希望能針對這二者的差異做比較，並透過腦力激盪的方式，討論二個平臺未來的發展與商業模式。 OpenLab 訓練活動的主題是 Linux 驅動程式架構的 I/O 模型，我們將延伸第一次的訓練內容，針對 device file 的 read/write 做介紹。活動即日起開放報名，訓練活動同樣採取限額方式。OpenLab 入口網頁：http://wiki.openmoko.org/wiki/OpenLab/zh_tw，報名網址：http://wiki.openmoko.org/wiki/OpenLab_2nd_Event/zh_tw。

Rubin: "One of the interesting things about Google's business is the flexibility and relevance... part of this Android solution is a very robust HTML web browser... contrary to a lot of the speculation out there, you won't see a completely ad-driven cellphone based on this platform."

Eric: "The fundamental problem with most phones today is they don't have full-power browsers. We've been taking our mobile services and use specialized engineering to get them on other devices...

The people inside FIC are amazingly open-minded. Our CEO and Chairman are the two greatest supporters inside this company. Earlier this month they did something courageous and support of the communities commitment.

有別於 xorg-server 裡的其他 X server，KDrive 並不基於以往的 XFree86 程式碼，而是由 Keith Packard 所實作的新版本；目前，KDrive 已被應用在許多 embedded system 的專案中。例如，OpenMoko 的 framework 就是使用 KDrive。

KDrive 另外一個特色是，他並不是像典型的 X server 是在動態時期去載入一些設定，而是在編譯時間就做好參數的設定。

Xorg-server 從 7.1 開始，已經將 KDrive 整合進來，只要下載 xorg-server 7.1 或更新版本的原始碼，裡頭就包含了 KDrive。以 xorg-server 7.2 來說，要設定 X server 為 KDrive 的話，只要將 KDrive 參數打開，並將其他的 X server 關閉即可。例如：

 ./configure \
--host=arm-linux \
--disable-composite \
--enable-kdrive \
--disable-dga \
--disable-dri \
--disable-xinerama \
--disable-xf86misc \
--disable-xf86vidmode \
--disable-xorg \
--disable-xorgcfg \
--disable-xkb \
--disable-xnest \
--disable-xvfb \
--disable-xevie \
--disable-xwin \
--disable-xprint \
--disable-xtrap \
--disable-dmx \
--disable-w100 \
--disable-xsdl \
--disable-xephyr \
--with-default-font-path=built-ins \

目前，KDrive 在 embedded Linux 的應用中，底層部份大多是透過 native framebuffer（fbdev、/dev/fb）來做圖形的顯示。

今天在 Linuxdevices.com 上再度看到 UME（Ubuntu Mobile and Embedded）的新消息了：「Ubuntu's mobile and embedded project advances」。關於此 project 的最新情況，引述一段報導原文如下：

UME is working to port Ubuntu to lpia, starting with an lpia bootloader and a port of the Hildon application framework, best known for its use in the Nokia 770 and N800 Internet tablets.

LPIA（Low Power on Intel Architecture）是 Intel 最新的省電技術專案，UME 正在將 Ubuntu 移植到此架構上。UME 專注的目標是：

UME goals apparently include outstanding multimedia playback and web browsing, along wtih fast boot and resume times, and small memory and disk footprints.

其它更詳細的資訊可閱讀 UME's Wiki。這真是忙碌的一週，大部份時間都在做協調的工作，一些技術研究也停了好幾天了，正好利用一個早上的空擋來讀書，整理技術資料。

在今年的 Computex Taipei 上，看到了非常多 MID 概念的產品，共同的特色當然就是他們都具備輕巧的工業設計，這是「入市」（進入市場競爭行列）的門票；此外，單就技術面來說，另一張門票應該會是開機時間、suspend與電池的技術掌握能力。

延伸閱讀

Asian Linux distributor TurboLinux today announced the "global launch" of its combination PMP (portable media player) and Linux boot device.

這個 TurboLinux 的 PMP（稱為 Wizpy）其實和以往傳統的 PMP 產品，概念上有點差異，這告訴我們一件事情，就是以前老師有教過的，產品的定位與名詞一定要突顯「差異」，否則人家一看是 PMP 連標題都草草帶過，何況是要讀者移動滑鼠在「more」上點一下。

TurboLinux 的 PMP 有「boot device」的功能，引述一段報導的原文如下：

When plugged into a PC, the "Wizpy" player launches users into their own localized, personalized Linux-based operating system environment.

這其實有點像「USB 開機隨身碟」。但是，只把 Linux 做到 USB 隨身碟，再用 BIOS 的 USB 開機功能啟動 Linux，似乎無法彰顯「device」的價值。Wizpy 現在也加入了 portable media player 的功能，馬上就能突顯 device 的價值。

Wizpy 的報價大約是一萬塊台幣左右，姑且不論這個價格是否夠吸引人，單就產品的感覺來說，花一萬塊買「可開機的 USB 身碟」是很不合理的事情，但是如果是花錢買「PMP、可開機」的 USB 裝置，掏錢的感覺就整個不一樣了。

此外，也提到 co-routine（協同式多工）的概念，建議可先行閱讀 [jserv] 兄的「使用 coroutine 實做 user-level thread」。

只以程式語言的技巧，來實作「多工」是一種很有用的做法，課程中，撰寫了一個「stack-based coroutine」的簡單實例，程式碼如下：

#include <stdio.h>
#include <pthread.h>

int count = 0;
int state = 0;

#define CHECK_POINT      \
if (count > 3) { \
   count = 0; \
   state = 1; \
   return; \
}

int foo(void)
{
   static unsigned int i;

   switch (state) {
        case 0: goto L0;
        case 1: goto L1;
   }
L0: /* start of function */
   i = 0;

   while (1) {
      i++;
      CHECK_POINT;
L1:
      printf("i = %d\n", i);
      if (i == 30) break;
      sleep(1);
   }

   printf("---------- foo exits ------------\n");
   state = 0;
   return 0;
}

void *counter(void *p)
{
   while (1) {
      count++;
      sleep(1);
   }
}

int main(void)
{
   pthread_t tid;
   pthread_create(&tid, NULL, &counter, NULL);

   count = 0;
   state = 0;

   while (1) {
      foo();
      printf("Enter event looping ...\n");
   };
}

Stack-based coroutine 是一種基於「function call」的「交錯執行」做法，最大的用途是，我們可以在「event handler」裡埋入「check point」，以達到「協同式」多工的效果。

$ ./co
i = 1
i = 2
i = 3
i = 4
Enter event looping ...
i = 5
i = 6
i = 7
i = 8
Enter event looping ...
i = 9
i = 10
...
Enter event looping ...
i = 29
i = 30
---------- foo exits ------------
Enter event looping ...
i = 1
i = 2
i = 3
Enter event looping ...
i = 4

就程式碼內部的組織來說，以往我們經常重新定義一些基本的東西，並透過這些 're-defidition' 的巨集或函數（亦稱為 wrapper function）來撰寫程式。有時，也能透過重新定義的方式，將框架（framework）的實作隱藏起來。這種技巧，大量被應用在許多軟體專案中。

Glib 小談

Glib 是 GTK+ 計畫下的「副產品」，Glib 原本主要是給 GTK+ 與 GNOME 使用，不過，現在也有越來越多的應用程式開始使用 Glib 來開發軟體。Glib 就本質來看，他提供一套重新定義過的 data type、event loop 框架、thread 框架、以及物件（object）系統。

Glib 以一種「宏觀」的方式，提供 C 語言一套高度可攜性、簡單易學且通用的工具庫（toolkit）。由於 Glib 實在太優異了，除了 GTK+ 與 GNOME 本身外，也有非常多的 Free / Open Source Software 也開始採用 Glib 來開發軟體。

Glib 主要提供的內容，以及使用 Glib 來撰寫程式時需要具備的核心觀念，簡單說明如下。

Data Type

Glib 提供一組簡單易用且可攜性佳的 data type 定義。例如，我們想要擺放身高的資料，那麼傳統的 ANSI C 會以 unsigned int 來宣告變數；但是，改用 Glib 來做的話，就要改用 guint 這個由 glib 提供的 data type 來宣告變數。

以 guint 來說，Glib 的內部實作為：

typedef unsigned int	guint;

雖然 Glib 仍以 ANSI C 的 data type 來定義 guint，但提供了高度可攜的 data type。

Event Loop

以前，如果您要規劃一套以事件驅動（event-driven）為主的應用程式框架（application framework），在 event loop 的設計上常會遭遇到許多困難；我想，對 Linux system programming 有經驗的朋友，也一定曾遇過「如何與硬體事件整合」的麻煩題目。

Event loop 的程式架構往往「長的很像」，所以我們以前常會思考，是否能寫出一套「萬用」的 event loop 框架；以後，只要是撰寫事件驅動程應用程式，就照著套用就好了！

Glib 把這個想法實現了。對於「core application」的支援，Glib 不僅提供一套宏觀且通用的 event loop 定義，連其他好用的技術也都一併定義完成了。

我們在規劃程式的核心架構時，經常使用的技術也都有包含在 Glib 的支援裡。除了 Event Loop 外，還包含：

• Threads
• Dynamic Loading of Modules，也就是 plug-ins 的功能。
• Memory Allocation
• IO Channels，也就是檔案、pipes 與 sockets 的功能。
• Message Output and Debugging Functions，常常用 printf() 在做除錯嗎？Glib 也定義了一組通用的介面！
• Message Logging

天啊！真是太好了，Glib 把以前常用的技術都「提出共通的部份」，讓我們更容易寫程式。

Threads

POSIX thread（亦稱為 pthread）是重要的 Linux user-space thread 函數庫，雖然 pthread 並無法做到所謂的「效能提昇」，但是因為 application framework 規劃的需要，因此還是被大量採用。以往，有鑑於 thread 的產生與管理經常都是「差不多」的程式碼，因此我也會定義一組屬於自己的 thread 通用 API，大部份都是以 macro 形式來定義。Glib 也提供一組彈性相當好、高度可移植且容易使用的 thread 介面，透過 Glib 的定義來實作 multi-threaded application 不但簡單，而且也很容易管理所有的 thread。 《待續》

來源: www.jollen.org

-rw-r--r-- 1 jollen jollen 119555927 2007-05-17 21:05 openmoko-toolchain-20070517.tar.bz2

1 /*
2  *  linux/include/asm-arm/map.h
3  *
4  *  Copyright (C) 1999-2000 Russell King
5  *
6  * This program is free software; you can redistribute it and/or modify
7  * it under the terms of the GNU General Public License version 2 as
8  * published by the Free Software Foundation.
9  *
10  *  Page table mapping constructs and function prototypes
11  */
12 struct map_desc {
13         unsigned long virtual;
14         unsigned long pfn;
15         unsigned long length;
16         unsigned int type;
17 };
18 
19 #define MT_DEVICE               0
20 #define MT_CACHECLEAN           1
21 #define MT_MINICLEAN            2
22 #define MT_LOW_VECTORS          3
23 #define MT_HIGH_VECTORS         4
24 #define MT_MEMORY               5
25 #define MT_ROM                  6
26 #define MT_IXP2000_DEVICE       7
27 #define MT_NONSHARED_DEVICE     8
28 
29 #ifdef CONFIG_MMU
30 extern void iotable_init(struct map_desc *, int);
31 #else
32 #define iotable_init(map,num)   do { } while (0)
33 #endif
34 

這是一個非常「輕薄」的設計，以 Jollen-Kit! Pro. 開發板來說，我的實作程式碼如下：

diff -Naur linux-2.6.20.4_orig/arch/arm/mach-s3c2410/mach-smdk2410.c linux-2.6.20.4/arch/arm/mach-s3c2410/mach-smdk2410.c
--- linux-2.6.20.4_orig/arch/arm/mach-s3c2410/mach-smdk2410.c	2007-03-24 03:52:51.000000000 +0800
+++ linux-2.6.20.4/arch/arm/mach-s3c2410/mach-smdk2410.c	2007-04-04 17:48:05.000000000 +0800
@@ -55,7 +55,13 @@
 #include "common-smdk.h"
 
 static struct map_desc smdk2410_iodesc[] __initdata = {
-  /* nothing here yet */
+    /* ISA IO Space mapping for CS8900. Memory space is selected by A24. */
+        {
+                .virtual        = 0xd0000000,
+                .pfn            = S3C24XX_PA_CS8900,
+                .length         = 0x00100000,
+                .type           = MT_DEVICE,
+        }
 };

程式碼簡單乾淨，這能讓不懂 kernel 的硬體開發人員也能快速上手維護。這讓我們了解到，一些「抽象」設計的 kernel 程式碼，雖然在某個程度來說，會讓 developer 多花一些時間才能 trace 到底層，但卻能適度提供硬體開發人員一些彈性空間。例如，不需要懂 kernel 的硬體工程師，也能有自行修改 IO mapping 設定的能力。

附帶一提，S3C24XX_PA_CS8900 是 IO memory 的實體位址（physical address）。

Contrary to widespread rumors, Ubuntu Mobile will not target mobile phones. Instead, the "mobile and embedded" version of the popular desktop Linux distribution will be developed in partnership with Intel, and will target "mobile Internet devices" (MIDs), along the lines of Nokia's N800 web tablet.

We will start more detailed planning at the Ubuntu Developer Summit next week in Seville and the first release of this edition will be in October with Ubuntu 7.10. If you are interested in the project, please get involved. We will be working through our normal development processes on Launchpad, the developer mailing lists and IRC.

雖然 Linux 2.6.21 早在二星期前就釋出，不過近期業務繁忙，一直到這幾天才能安排這項工作。

本次更新包含了以下幾個與我有關，或是較感興趣的項目：

1. VMI 驅動程式如果先前所提到的消息，已正式加入 kernel。

2. 值得注意的是，KVM 驅動程式也加入了 "paravirtualized" 的支援，"paravirtualized KVM" 驅動程式在 context-switch 的效能上有相當大的改進。此部份可參考 LKML 裡的原文：[[announce] [patch] KVM paravirtualization for Linux]。

3. "devres" subsystem 的更新，讓我們在撰寫驅動程式時，更容易 allocation / map "resource"，例如：IRQ request、memory mapped I/O 等；devres 簡化驅動程式的 resource allocation / map 程式碼，詳細介紹可參考 [The managed resource API]。

4. Embedded Linux 的應用經常需要撰寫 GPIO 相關的驅動程式，現在 Linux 2.6.21 加入了 GPIO API 的支援。

5. ARM 的部份，加入了 Samsung s3c2443 的 SOC 支援

6. 此外，知名的 Samsung s3c2410 clone 'QT2410' 也正式加入至 Linux 2.6.21；另人有點小驚訝的是，這個 patch 是由 OpenMoko 所貢獻的實作：

1 /* linux/arch/arm/mach-s3c2410/mach-qt2410.c
2  *
3  * Copyright (C) 2006 by OpenMoko, Inc.
4  * Author: Harald Welte <laforge@openmoko.org>
5  * All rights reserved.
6  *
...

延伸閱讀

2007.03.29: Kernel 2.6.21 將正式加入 VMI（Virtual Machine Interface）

2006.10.19: Kernel 2.6 的 KVM (Kernel Virtual Machine) 驅動程式來了

             Neo1973  iPhone   M600i   LG Prada
length (mm)   120.7    115      107     98.8
width         62       61       57      54
height        18.5     11.6     15      12
weight (g)    184      135      112     85
screen (inch) 2.8      3.5      2.6     3.0

Kernel synchronization 的機制中，semaphore 有二種版本可供使用：

- Semaphore: down(), up()

- Spinlock

二種不同的 semaphore 實作的差異在於「P operation」的實作：

- down/up, 採取 sleeping 方式

- spinlock, 採取 busy loop 方式

在 interrupt handler 的實作上，由於 kernel 並非與 process context 做切換（kernel 執行的是 interrupt-context code），無法進行系統的 rescheduling，所以只能使用 spinlock 來進入 critical section。另外，我們提到，在 process-context mode 也常會看到 spinlock 的使用；在一般的 system call 實作函數裡，為什麼用 spinlock 而不是典型的 down/up 呢？道理在於，「如果 P operation 的等待時間相當短暫（semaphore holding 的時間很短），那麼使用 busy-loop 的方式便會比排程 task 為 INTERRUPTIBLE/UNINTERRUPTIBLE 狀態（sleep）來得更有效率」。

Linux 提供了三類的 spinlock API：

- IRQ don't care, 不對 local interrupt 做任何設定

- IRQ disabling, 將 local interrupt 設定為 disable

- IRQ save/restore, 儲存/還原 local interrupt 狀態

狀況一：當我們選擇在 non-interrupt mode 或是 process-context mode 使用 busy-loop 版本的 semaphore 時，若要確保 critical section 為 atomic operation，或是與 interrupt handler 做同步，此時就必須使用 IRQ disabling 的 spinlock，以確保 critical section 不會被 interrupt 打斷，且讓 processor 不會再接受任何的 interrupt。IRQ-disabling spinlock API 如下：

- spin_lock_irq

- spin_unlock_irq

同學可查閱課堂所發的補充資料，觀念上的疑問，可透過 forum 來詢問。

來源: Jollen's Blog

當 user-space 呼叫 mmap() system call wrapper function 後，kernel 會在 process address space 裡建立新的 VMA，並在 callback mmap driver function 時將「該」VMA 傳遞給我們的驅動程式。

因此，在驅動程式裡，只需要利用 remap_page_range() 將 kernel-space 的 memory：

- I/O memory

- RAM（reserved pages）

- Virtual address space（reserved pages）

對應到該 VMA 即可。最後，寫出了以下的 skeleton code：

// refer to: bttv-dirver.c
int do_card_mmap(struct vm_area_struct *vma, char *adr, unsigned long size)
{
    unsigned long start = (unsigned long)adr;
    unsigned long page, pos;

    pos = (unsigned long)BaseIOAddress;
#if 1  // page or the total size ?
    while (size >0) {
       page = pos;
       if (remap_page_range(vma, start, page, PAGE_SIZE, PAGE_SHARED))
	   return -EAGAIN;
       start+=PAGE_SIZE;
       pos+=PAGE_SIZE;
       size-=PAGE_SIZE;
    }
#else
    if (remap_page_range(vma, start, pos, size, PAGE_SHARED))
       return -EAGAIN;
#endif
    return 0;
}

// refer to: videodev.c
int card_mmap(struct file *filp, struct vm_area_struct *vma)
{
   do_card_mmap(vma, (char *)vma->vm_start, (unsigned long)(vma->vm_end-vma->vm_start));
   return 0;
}
/**************************************************/

struct file_operations card_fops = {
  open:card_open,
  release:card_release,
  ioctl:card_ioctl,
  mmap:card_mmap,
};

remap_page_range() 的原理是去修改 page table，但是要不要以 "page" 為最小單位做 page table 的修改（呼叫 'remap_page_range'），必須視情況而定！

同學對此部份如有觀念上的疑問，可透過 forum 討論。

來源: Jollen's Blog

相關應用，例如，我們只要觀察 r15（pc）暫存器的值，就可以知道現在這台機器的程式執行位置。實際上的應用，像是 qemu 所實作的 gdbserver 即是透過此 object 的資訊，來回覆 gdb client 的命令。

以下展示實際的操作畫面。

下圖是利用 jk2410-emulator 模擬 Jollen-Kit! Pro. 的開機畫面，使用的 kernel 是 2.6.20.4：

在 kernel 檢查 root filesystem 是否為 initramfs 的時候，我們啟動了 gdb client，並透過 socket 連到 qemu 的 gdbserver；為了方便進行 source-level debug，我們使用 cgdb 來操作，下圖是 debug 畫面：

我們可以看到，此時 kernel 正執行到 lib/inflate.c 裡的第 59x 行程式，我們利用 next 做單步執行。這種「一邊跑 kernel，一邊看 kernel 跑到哪一個原始檔的哪一行」正是使用 qemu 做「整體系統」除錯的關鍵突破之一。

回到 qemu，找到 gdbserver 的實作 'gdbstub.c'；當 host 的 gdb（gdb client）端對 target 端 gdb server 下命令時（透過 gdb remote protocol），qemu 實作的 gdb server 會先由 CPUState 讀取 register 的內容，再回應給 gdb client。gdb remote debug protocol 顯然不是我們目前的重點，所以先找到 'gdbstub.c' 關於「讀取 ARM 處理器 register」的主要程式片斷如下：

#elif defined (TARGET_ARM)
static int cpu_gdb_read_registers(CPUState *env, uint8_t *mem_buf)
{
    int i;
    uint8_t *ptr;

    ptr = mem_buf;
    /* 16 core integer registers (4 bytes each).  */
    for (i = 0; i < 16; i++)
      {
        *(uint32_t *)ptr = tswapl(env->regs[i]);
        ptr += 4;
      }
    /* 8 FPA registers (12 bytes each), FPS (4 bytes).
       Not yet implemented.  */
    memset (ptr, 0, 8 * 12 + 4);
    ptr += 8 * 12 + 4;
    /* CPSR (4 bytes).  */
    *(uint32_t *)ptr = tswapl (cpsr_read(env));
    ptr += 4;

    return ptr - mem_buf;
}

gdb server 回傳給 host 端的資訊，已經由 host 端的 gdb 為我們解析，並根據 debug sections 來找到 $pc 對應的原始程式位置，即 source-level debug。

由於這種除錯模式，是對「整粒 ARM 處理器」做除錯，概念上很像是 jtag debug，因此會比用 kgdb 或 kdb 來得實用。原理上來看，gdb 單純是對 qemu 做除錯，而 qemu 是一個可以讓「完整 Linux 系統」在上面執行的 'system emulator'（for various processors），所以我們可以對模擬器裡頭的程式概念上「直接」進行除錯，因為對 host 端的 gdb 來說，這是通透的（transparent）。

再者，對除錯的二大重要工作：source-level debug 或是「單步執行」來說，qemu 單純只回應 $pc 給 gdb client，qemu 並不會知道現在跑的程式是什麼，同時也不需再加入（或修改）gdb stub 至 kernel 或 application，這樣的通透性，讓此種除錯模式可說是非常「萬能」的。不過，在實務上仍有一些不足的地方，例如，我們需要在 host 端編譯出具備除錯資訊的程式，才能搭配 qemu 來除錯，並且，也要小心注意 host 端的 loaded ELF image 與 run-time 的程式是否相同。

高通透性並非全然都是好的，例如，即使 loaded kernel image（vmlinux）與 run-time kernel 不同，我們還是會看到「目前跑到 source code 什麼地方」，因此目前的 source code 位置與 $pc 的位址是對不起來的。實務上，host gdb 透過 qemu 來除錯 kernel 的高度通透性，也帶來了一些小問題，有機會再做整理分享，或許可在 [OrzLab] 的讀書會上提出討論。

不過，如果是因為忘了重新打包 kernel，就直接跑 emulator 進行除錯，而發生上述的錯誤，實在是非戰之罪。

來源: Jollen's Blog

程式所需的程式庫，稱為相依性程式庫，即 library dependencies；並且，程式庫也會再相依其他的程式庫，因此，找出 library dependencies 是一種拓樸邏輯關係。

由 dynamic linker 的實作角度來說，程式的 library dependencies 紀錄在 dynamic segment 的 DT_NEEDED entry 裡，dynamic linker 便是由 DT_NEEDED 為起點，建立 library dependencies 關係圖，此圖又稱做 NEEDED list。

例如，若程式相依 libm 與 libc，那麼，DT_NEEDED entry 的內容就會是：

# readelf -d test

Dynamic segment at offset 0x494 contains 21 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libm.so.6]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000000c (INIT)                       0x80482a4
 0x0000000d (FINI)                       0x8048460
...

使用 ldd 也能觀察到 library dependencies：

# ldd test
        libm.so.6 => /lib/tls/libm.so.6 (0x40026000)
        libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

熟悉 embedded Linux 系統建置的朋友想必對這個部份不感到陌生，現在我們終於知道 library dependencies 是紀錄在 dynamic segment 的 DT_NEEDED 裡，對於 dynamic linking 的研究又跨出了一大步。

來源: Jollen's Blog

Dynamic section 是整個 dynamic linking 體 系的觀念核心，絕對不能放過；在 System V ABI 規格中，有詳細的 dynamic section 介紹。Dynamic section 裡頭包含多個 'entry'，每一個 entry 紀載不同的資訊。首先，我們先找出 dynamic section 的資料結構定義如下：

/* Dynamic section entry.  */

typedef struct
{
  Elf32_Sword   d_tag;                  /* Dynamic entry type */
  union
    {
      Elf32_Word d_val;                 /* Integer value */
      Elf32_Addr d_ptr;                 /* Address value */
    } d_un;
} Elf32_Dyn;

'd_tag' 用來標記該 entry 的用途，'d_val' 或 'd_ptr' 則是該 entry 的內容。完整的 dynamic section 有哪些 entry？以及每一個 entry 的用途說明為何？此部 份請參閱 System V ABI 文件的說明，該文件有一份列表整理出所有的 dynamic section entry 及其說明，在此不再重覆刊載。不過，我們可由 elf.h 來快速了解 dynamic section 裡的主要（generic, processor-independent） entry：

/* Legal values for d_tag (dynamic entry type).  */

#define DT_NULL         0               /* Marks end of dynamic section */
#define DT_NEEDED       1               /* Name of needed library */
#define DT_PLTRELSZ     2               /* Size in bytes of PLT relocs */
#define DT_PLTGOT       3               /* Processor defined value */
#define DT_HASH         4               /* Address of symbol hash table */
#define DT_STRTAB       5               /* Address of string table */
#define DT_SYMTAB       6               /* Address of symbol table */
#define DT_RELA         7               /* Address of Rela relocs */
#define DT_RELASZ       8               /* Total size of Rela relocs */
#define DT_RELAENT      9               /* Size of one Rela reloc */
#define DT_STRSZ        10              /* Size of string table */
#define DT_SYMENT       11              /* Size of one symbol table entry */
#define DT_INIT         12              /* Address of init function */
#define DT_FINI         13              /* Address of termination function */
#define DT_SONAME       14              /* Name of shared object */
#define DT_RPATH        15              /* Library search path (deprecated) */
#define DT_SYMBOLIC     16              /* Start symbol search here */
#define DT_REL          17              /* Address of Rel relocs */
#define DT_RELSZ        18              /* Total size of Rel relocs */
#define DT_RELENT       19              /* Size of one Rel reloc */
#define DT_PLTREL       20              /* Type of reloc in PLT */
#define DT_DEBUG        21              /* For debugging; unspecified */
#define DT_TEXTREL      22              /* Reloc might modify .text */
#define DT_JMPREL       23              /* Address of PLT relocs */
#define DT_BIND_NOW     24              /* Process relocations of object */
#define DT_INIT_ARRAY   25              /* Array with addresses of init fct */
#define DT_FINI_ARRAY   26              /* Array with addresses of fini fct */
#define DT_INIT_ARRAYSZ 27              /* Size in bytes of DT_INIT_ARRAY */
#define DT_FINI_ARRAYSZ 28              /* Size in bytes of DT_FINI_ARRAY */
#define DT_RUNPATH      29              /* Library search path */
#define DT_FLAGS        30              /* Flags for the object being loaded */
#define DT_ENCODING     32              /* Start of encoded range */
#define DT_PREINIT_ARRAY 32             /* Array with addresses of preinit fct*/
#define DT_PREINIT_ARRAYSZ 33           /* size in bytes of DT_PREINIT_ARRAY */
#define DT_NUM          34              /* Number used */

本系列專欄將針對以 下幾個重要的 entry type 做觀念上的分享：

• DT_NEEDED     1 /* Name of needed library */
• DT_HASH          4 /* Address of symbol hash table */
• DT_STRTAB      5 /* Address of string table */
• DT_SYMTAB     6 /* Address of symbol table */

我們可使用 Linux 常見的 ELF 工具 - 'readelf' 來觀 察 ELF executables 的 dynamic segment 資訊：

# readelf -d test

Dynamic segment at offset 0x404 contains 20 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000000c (INIT)                       0x8048230
 0x0000000d (FINI)                       0x80483d0
 0x00000004 (HASH)                       0x8048128
 0x00000005 (STRTAB)                     0x80481a0
 0x00000006 (SYMTAB)                     0x8048150
 0x0000000a (STRSZ)                      75 (bytes)
 0x0000000b (SYMENT)                     16 (bytes)
 0x00000015 (DEBUG)                      0x0
 0x00000003 (PLTGOT)                     0x80494e0
 0x00000002 (PLTRELSZ)                   16 (bytes)
 0x00000014 (PLTREL)                     REL
 0x00000017 (JMPREL)                     0x8048220
 0x00000011 (REL)                        0x8048218
 0x00000012 (RELSZ)                      8 (bytes)
 0x00000013 (RELENT)                     8 (bytes)
 0x6ffffffe (VERNEED)                    0x80481f8
 0x6fffffff (VERNEEDNUM)                 1
 0x6ffffff0 (VERSYM)                     0x80481ec
 0x00000000 (NULL)                       0x0

對於 dynamic linking 的說明，後續會先行整理這 4 個 entry 的主要觀念，然後再針對「如何找到程式所需（depends）的程式庫」做分析，並談論有關符號（symbol）的連結（relocation）處 理機制。

來源: Jollen's Blog

#elif defined(TARGET_ARM)
#define CPUState CPUARMState
...

我們以 ARM 做為 target，再找到 target-arm/cpu.h：

typedef struct CPUARMState {
    /* Regs for current mode.  */
    uint32_t regs[16];
    /* Frequently accessed CPSR bits are stored separately for efficiently.
       This contains all the other bits.  Use cpsr_{read,write} to access
       the whole CPSR.  */
    uint32_t uncached_cpsr;
    uint32_t spsr;

    /* Banked registers.  */
    uint32_t banked_spsr[6];
    uint32_t banked_r13[6];
    uint32_t banked_r14[6];
    
    /* These hold r8-r12.  */
    uint32_t usr_regs[5];
    uint32_t fiq_regs[5];
    
    /* cpsr flag cache for faster execution */
    uint32_t CF; /* 0 or 1 */
    uint32_t VF; /* V is the bit 31. All other bits are undefined */
    uint32_t NZF; /* N is bit 31. Z is computed from NZF */
    uint32_t QF; /* 0 or 1 */

    int thumb; /* 0 = arm mode, 1 = thumb mode */

    /* System control coprocessor (cp15) */
    struct {
        uint32_t c0_cpuid;
        uint32_t c0_cachetype;
        uint32_t c1_sys; /* System control register.  */
        uint32_t c1_coproc; /* Coprocessor access register.  */
        uint32_t c2; /* MMU translation table base.  */
        uint32_t c3; /* MMU domain access control register.  */
        uint32_t c5_insn; /* Fault status registers.  */
        uint32_t c5_data;
        uint32_t c6_insn; /* Fault address registers.  */
        uint32_t c6_data;
        uint32_t c9_insn; /* Cache lockdown registers.  */
        uint32_t c9_data;
        uint32_t c13_fcse; /* FCSE PID.  */
        uint32_t c13_context; /* Context ID.  */
        uint32_t c15_cpar; /* XScale Coprocessor Access Register */
    } cp15;

    /* Coprocessor IO used by peripherals */
    struct {
        ARMReadCPFunc *cp_read;
        ARMWriteCPFunc *cp_write;
        void *opaque;
    } cp[15];

    /* Internal CPU feature flags.  */
    uint32_t features;

    /* exception/interrupt handling */
    jmp_buf jmp_env;
    int exception_index;
    int interrupt_request;
    int user_mode_only;
    int halted;

    /* VFP coprocessor state.  */
    struct {
        float64 regs[16];

        uint32_t xregs[16];
        /* We store these fpcsr fields separately for convenience.  */
        int vec_len;
        int vec_stride;

        /* Temporary variables if we don't have spare fp regs.  */
        float32 tmp0s, tmp1s;
        float64 tmp0d, tmp1d;
        
        float_status fp_status;
    } vfp;

    /* iwMMXt coprocessor state.  */
    struct {
        uint64_t regs[16];
        uint64_t val;

        uint32_t cregs[16];
    } iwmmxt;

#if defined(CONFIG_USER_ONLY)
    /* For usermode syscall translation.  */
    int eabi;
#endif

    CPU_COMMON

} CPUARMState;

這個 object 是 qemu 用來紀錄 ARM 處理器狀態的資料結構，舉例來說，CPUState.regs 紀錄了 ARM 的所有 register 狀態。相關應用，例如，我們只要觀察 r15（pc）暫存器的值，就可以知道現在這台機器的程式執行位置。實際上的應用，像是 qemu 所實作的 gdbserver 即是透過此 object 的資訊，來回覆 gdb client 的命令。

#define ARM_CPUID_ARM920T 0x41129200

int qemu_register_machine(QEMUMachine *m)
{

    QEMUMachine **pm;
    pm = &first_machine;
    while (*pm != NULL)
        pm = &(*pm)->next;
    m->next = NULL;
    *pm = m;
    return 0;
}

QEMUMachine neo1973_machine = {
    "neo",
    "Neo1973 phone aka FIC GTA01 aka OpenMoko (S3C2410A)",
    neo_init,
};

/* This is the Linux kernel elf-loading code, ported into user space */

TS(n) = n * T
TD(n) = n * T

TS_battery_key(100)

Turn around time of event 'battery_key' = TS_battery_key(100) + TD_battery_key(150) = T(100) + T(150) = 100T + 150T = 250T

Turn around time of event 'battery_key' <= Taccept_battery_key(300) = T(300)

最近跟朋友弄了一個實驗室，想法是能讓更多創意透過自由軟體，落實於嵌入式裝置或者特定的硬體中，這個實驗室名稱為 "Open RazzmatazZ Laboratory "，簡稱 OrzLab，一言以蔽之，訴求就是： "Open RazzmatazZ Laboratory (OrzLab) funds an environment for freedom and creativity based on Free Software and Open Source efforts."

避免重複的專案開發，並針對嵌入式系統或系統整合廠商需求，提出有價值的解決方案，建構一系列自由軟體為基礎的系統架構。也因此，針對特定主題，開發出足夠好且高度創意的專案，並確保以 GPL / BSD License / MIT X License 釋出。

OrzLab 成員來自台灣的自由軟體貢獻者，以 Linux/BSD 為主要的開發環境，對嵌入式系統開發、多國語文處理、Web 應用程式，或者是低階系統控制皆有一定的掌握度。

+----------------------------+  \
|    Linux Kernel            |    \
+----------------------------+      => Virtualized OS
|    VMI                     |    /
+----------------------------+  /
|    Hypervisors             |  ====> VMM (eg. Xen)
+----------------------------+
|   虛擬化功能 CPU           |
+----------------------------+

作業系統（Operating System）的研究，我們以 Linux kernel 的探討來說明一些應有的正確觀念。

對於 Linux kernel 的研究，最經常聽到有人提起「kernel source code」的研讀與分析，並且最常看到的研究方式為「尋找 kernel 進入點，並依照程式流程（flow）做循序研究」，不過，這卻是一種「大部份情況下都錯誤」的研究方式。

由於電腦系統是一種 foreground-background system，並且 Linux kernel 是在此系統上的作業系統，因此整體的 kernel 行為是「control patch」，也就是「控制權的轉移」與「系統狀態的改變」，並不是「程式（函數）流程（flow）」，或是「程式結構（structure）」的問題；最近有朋友問起這方面的議題， 正好也在進行 Linux device driver 的 training，因此特別整理這則日記，來與大家分享，若有任何論述上的失誤，或是有不同的觀點，歡迎在這裡留言 分享。

許多人對於「作業系統」的觀念可能真的有點薄弱；具體來說，對於 kernel 內部原理的研究，其方法應該是：

1. kernel 的開機階段，是以「流程（flow）」的角度來做討論。

2. kernel 完成開機後，會執行 init process，由此正式切換到 F/B system 的觀念，也就是整個系統是一個偌大的狀態機，整個系統內部是一連串複雜的控制權轉移動作。

最近朋友希望我能針對「kernel 的執行流程」做簡單介紹，但是這個問題在命題上應當有修正或是觀念澄清的空間。由於電腦本身是一種 foreground-background system，因此 foreground 的工作會影響 CPU 將控制權移交到 background 的哪一個部份；如果把 user-space 當成 foreground，kernel-space 當成 background，那麼整體系統便能以下圖表示。

Background 受到 foreground 行為的影響，拿以下二個 process 為例，雖然執行結果相同，但因為 foreground 內部的行為不同，因此 control path 也會不同：

/* Process P */

int main(void)
{
   char buf[] = "Hello, World!";

   printf("%s", buf);
   return 0;
}



/* Process Q */

#define STR "Hello, World!"

int main(void)
{
   char *buf;

   buf = malloc(strlen(STR)+1);
   strcpy(buf, STR);
   
   printf("%s", buf);
   return 0;
}

此時，仍是以「流程圖」邏輯來思考的話，當然無法領會箇中奧妙。簡單二個不同的 process，CPU 將控制權移轉到作業系統的路徑（也就是 kernel 執行了哪些程式碼），居然有這麼大的差異。如果再把排程器（scheduler）加入，那麼整個控制路徑很可能「不同時間執行同一程式」也會不同。Tricky！

以研究方法來說，命題時觀念的失誤，終將無法得到正確且完善的結論，因此「希望就 kernel 的執行流程」做討論的命題，應當做修正，並且給定一個更明確的題目； 再者，若無法體認 kernel 是一個大型的狀態機，而仍以「流程與程式結構」的觀念來思考，除了在問題的描述會有相當大的誤差外，可能也會對「如何了解 kernel source code」的方法摸不著頭緒。

由此可知，整體系統在 kernel 開完機並執行 init process 後，就必須針對其「行為」做分析與研究，而不是徘徊在「結構化 C 程式」的圈圈裡；這個觀念證明了「逐行看 code」並不是研究 kernel 原理的正確方法。

Kernel 本身的行為是一連串複雜的狀態改變與控制權轉移，因此是狀態機的觀念。至於，研究方法是採用流程或是控制路徑的觀念進行，就看我們想要讀的是哪一個部份的 source code。前面提到研究 kernel 的二個階段與方式，當中的轉捩點為 init process，接續 init process，建議可先由 program execution（process creation）的觀念開始切入，以了解整個作業系統的行為。

所以，kernel 的研究，是以其動態（run-time）時期行為（behavior）的分析與觀察為主。

來源: www.jollen.org

外部程式（stored program）的執行是透過 fork system call，先將 current process 複製一份成為他的 child process。接著再透過 exec system call 將外部程式的 ELF image 載入，並取代原來的 process。Kernel ELF loader 會讀取 ELF image，並將 text segment 與 data segment 重新 mapping，接著再找到程式的 program interpreter。

外部程式的最初執行是由 program interpreter 開始，program interpreter 透過 dynamic segment 完成 dynamic linking，此時完整的 process image 已建立完成；program interpreter 再跳到程式的進入點，也就是 C run-time library（crt?.o）。

以上二段文字說明了 program loading 的核心觀念，每一句子觀念都能做出一份不算短的分析報告；此階段只整理出 program loading 的主要重點，接著再把「dynamic linking」的主要觀念做研究後，大家應該就可以大致掌握「程式執行」的系統行為了。

另外，補充 program interpreter 的幾個觀念：

• program interpreter（ld.so）的存在形式有 shared object 與獨立執行檔二種。
• 當 program interpreter 是以獨立執行檔執行時，表示將 program interpreter 當成 dynamic loader/linker 來使用；通常是經由使用者直接下指令的方式來執行，program interpreter 在發展與測試階段時也使用這種方式。
• 當 program interpreter 是以 shared object 形式存在時，表示 program interpreter 是經由 kernel 來取得控制權；這種方式是將 program interpreter 當成 dynamic linker 來使用，這是較常見的做法。

以下是將 program interpreter 當做獨立執行檔的使用範例：

$ ldd hello
        libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$ /lib/ld-linux.so.2 ./hello
Hello, World!

關於 program loading 的分享到此做個小結，接下來將會整理有關 dynamic linking 的日記。

2) We don't have enough UI / Application developers -- If anybody
 meets (or knows somebody who can meet) the following qualifications:

        * >= 2 years experience with GTK
        * object oriented design and implementation w/ GObject
        * experience with writing GUI applications from scratch,
        * has software quality assets like:
         o writing maintainable and reusable code
         o refactoring
         o design patterns
         o identifying and extracting common application code
           into frameworks

 Familiarity with collaborative development tools such as:

        * bugtracker,
        * source control management,
        * wiki,
        * mailing lists

就非技術面的條件來看，幾個重要的「協同開發工具」成為了 Free / Open Source 開發者的必要技能，包含撰寫 Wiki 的能力也被列入考量的項目了。由這則徵人啟事的內容來看，幾個值得「傳統軟體開發人員」重視的條件有：

1. Free / Open Source 開發人員需要「refactoring」的技能：在不變動介面的前提下，進行現有程式碼的改善。

2. Free / Open Source 開發人員必須具備「辨認以及取出」程式碼至「framework」的能力：避免重造車輪，不要再去做別人已經做好的工作。

3. 會使用 wiki：非常贊成將編寫 wiki 的能力納入考量。

4. 會使用 mailing lists：這是基本條件，透過 mailing list 與 Free / Open Source 專案保持連絡，並與世界同步。

今天與幾位朋友分享並討論到這個議題，希望也能與大家分享，或是交流想法。

主旨: [openmoko-announce] RE: Crossroads 	完全表頭
 
Dear Community,

A big thanks again for all your feedback! We're meeting with vendors
this week and are optimistic about our chances to find a WiFi module.
We'll keep you all posted and announce the winner of the free phone once
we find the right solution.

As for the UI / Application developer work request, we're still
processing these emails. Please bare with us as we are just overwhelmed
with tasks trying to get the devices built this month.

-Sean

從「request for GPL WiFi module」到「meeting with vendors」也不過短短幾天，再度另人見識到開放源碼社群的力量。由於 OpenMoko 是一個完全開放的 Linux 手機平臺，並且 OpenMoko 所形成的 ecosystem 正在快速成熟穩定中，因此可以預見不久的未來，Linux phone 的發展與應用將會更加完整，解決方案（solution）的可獲取性（availability）也會更好。

• 2007.02.24: OpenMoko 的 gsmd：Linux 手機的 GSM Modem 通訊程式
• 2007.02.17: OpenMoko 釋出原始碼了
• 2007.01.22: OpenMoko 準備舉旗進攻了
• 2006.11.08: 「Mobile 2.0 的思考」與第一隻採用 OpenMoko 的 Linux Smartphone

在 IPC 的課程中提到 mapped memory 的行程間通訊機制，是透過「shared file」來做訊息的傳遞；將 shared file mapping 到 process address space 的 system call 為 'mmap()'。以下是其中一個簡單的程式範例 （mmap_write.c）：

#include <stdio.h> 
#include <fcntl.h>
#include <string.h>
#include <sys/mman.h>
#include <sys/stat.h>
#define FILE_LENGTH 0x400

int main(int argc, char *argv[])
{
   int fd;
   void *map_memory;

   /* Open a file to be mapped. */
   fd = open("/tmp/shared_file", O_RDWR | O_CREAT, S_IRUSR | S_IWUSR);
   lseek(fd, FILE_LENGTH+1, SEEK_SET);
   write(fd, "", 1);
   lseek(fd, 0, SEEK_SET);

   /* Create map memory. */
   map_memory = mmap(0, FILE_LENGTH, PROT_WRITE, MAP_SHARED, fd, 0);
   close(fd);

   /* Write to mapped memory. */
   if (strlen(argv[1]) < FILE_LENGTH)
      sprintf((char *)map_memory, "%s", argv[1]);

   sleep(10);

   exit(0);
}

當程式將檔案 mapping 到自己的記憶體空間（process address space）時，mmap system call 便會建立相對應的 VMA 區段；觀念上來說，只要透過 mmap system call 將檔案 mapping 到記憶體，便會產生對應的 VMA。

修改一下範例程式，讓程式在結束前小睡 10 秒鐘，並做觀察：

# ./mmap_write hello&
[1] 14667
# cat /proc/14667/maps
08048000-08049000 r-xp 00000000 16:42 213757     /tmp/mmap_write
08049000-0804a000 rw-p 00000000 16:42 213757     /tmp/mmap_write
40000000-40015000 r-xp 00000000 16:42 12828674   /lib/ld-2.3.2.so
40015000-40016000 rw-p 00014000 16:42 12828674   /lib/ld-2.3.2.so
40016000-40017000 rw-p 00000000 00:00 0
40017000-40018000 -w-s 00000000 16:42 213753     /tmp/shared_file
42000000-4212e000 r-xp 00000000 16:42 13991938   /lib/tls/libc-2.3.2.so
4212e000-42131000 rw-p 0012e000 16:42 13991938   /lib/tls/libc-2.3.2.so
42131000-42133000 rw-p 00000000 00:00 0
bfffe000-c0000000 rwxp fffff000 00:00 0

除了 mmap system call 外，IPC 技術中的 'shared memory' 同樣也能觀察到對應的 VMA 區段。

延伸閱讀

• 2007.01.05: Linux 的 Virtual Memory Areas（VMA）：基本概念介紹

• 2007.01.15: Linux 的 Virtual Memory Areas（VMA）：Process 與 VMA 整體觀念

1. 使用者在 shell 模式下執行外部程式（stored program）。

2. shell 以 fork+exec system call 的方式執行外部程式。

3. 透過 0x80H 軟體中斷（x86）叫用 kernel 的 exec（sys_execvp）system call service。

10. 所以任何 shared library 的外部程式，一開始都是由 program interpreter 開始執行！

15. 真正開始執行程式！

步驟 1.~6. 已在以下的日記介紹過：

• 2007.03.08: Process Creation, #6：Exec System Call 的觀念
• 2007.03.05: ELF 之 Program Loading 教學文件, #1: Segment 的觀念
• 2007.03.08: ELF 之 Program Loading 教學文件, #2: Program Header Table
• 2007.03.09: ELF 之 Program Loading 教學文件, #3: Segment Type 與 Kernel Space Loader

步驟 7.~15. 將會在後續的日記再做整理。以整體的 program loader 流程來說，可分為 kernel-space 與 user-space 二大階段：

• 步驟 4.~9. 由 kernel 的 ELF loader 所負責。
• 步驟 11.~14 由 user-space 的 program interpreter（dynamic loader/linker，也就是 /lib/ld-linux.so.2）所負責。

Program interpreter 需要 dynamic segment 裡的相關資訊來完成後續的工作，此部份日後再做整理分享。

來源: www.jollen.org

Program loading 時期會處理以下 4 種 segment：

#define PT_LOAD         1               /* Loadable program segment */
#define PT_DYNAMIC      2               /* Dynamic linking information */
#define PT_INTERP       3               /* Program interpreter */
#define PT_PHDR         6               /* Entry for header table itself */

簡要說明這 4 種 segment 的作用如下。

PT_LOAD：即 text segment 或 data segment。

PT_DYNAMIC：若 ELF 有此 segment，則表示 .dynamic section 會獨立成一個實體的 segment。PT_DYNAMIC 僅包含 .dynamic section。

PT_INTERP：紀錄 program interpreter 路徑與檔名的 segment。PT_INTERP 僅包含 .interp section。

PT_PHDR：Program header table segment。

Segment type 是很重要的資訊，kernel 的 ELF loader 與 program interpreter（ld.so）都是透過 segment type 來判斷 segment 的用途。

Kernel 與 program interpreter 對不同的 segment 都有不同的處理方式。

另外，PT_NOTE 並不是一個必要的 segment，實際上它也沒有重要的作用，因此忽略不做討論。

更多有關 Kernel ELF Loader

回到 Jollen's blog「Process Creation」專欄所談論到的「Program 載入流程」裡，相當重要的一個觀念就是 "exec" system call。程式的載入涉及 exec systegm call service，exec system call 是 machine-dependent 的實作，以 x86 來說，此服務實作於 linux/arch/i386/kernel/process.c 檔案；在 SystemV ABI 規格中，program loading 的章節 被撰寫在 'processor-specific' 文件裡。

在目前所討論的 ELF loading 主題中，我們還看不到與 processor 相關的議題，例如 .got/.plt 節區的用途；相關的技術細節在此較不適合做深入討論，未來會以分享一份技術簡報的方式來呈現，並且以 ARM 做為討論標地。

Exec system call 叫用 kernel space 的 ELF loader 載入 ELF image，此觀念請參考 Jollen's Blog「Process Creation, #6：Exec System Call 的觀念」。我們整理過 kernel 的 ELF loader 所做的工作有：

1. 讀取 ELF image 的 segment 資訊（由 program header table）。

2. 讀出 segment 內容。

3. 判斷是否有 program interpreter；若有，再讀取 program interpreter。

4. 將讀取到的 segment 內容取代掉 current 的內容，這個動作就是 exec system call 的重要特性。

項目 1. 是由 ELF image 的 program header table 分析執行檔的 segment 資訊，並判斷 segment type；ELF loader 會依照 segment 的類型來做不同的處理，說明如後（項目 2.）。

項目 3. 則是在找到 PT_INTERP  segment 時，呼叫 interpreter loader 將 interpreter 載入。Program interpreter 我們先前曾提過，就是 ld.so（dynamic loader/linker），這個部份將在下一篇日記再做說明。

PT_INTERP

若 ELF loader 判斷此 segment 為 PT_INTERP，則叫用 interpreter 的 loading 來做載入的工作，在標準的 GNU/Linux 系統底下，由於 program interpreter 也是 ELF 格式，因此叫用 kernel 的 load_elf_interp() API（fs/binfmt_elf.c）將 program interpreter 讀取並載入。

PT_LOAD

若 ELF loader 判斷此 segment 為 PT_LOAD，表示這是 text segment 或 data segment，也就是最主要的程式碼與資料區段，此時便透過 do_mmap() 來將 text/data segment mapping 到記憶體。

依照 ELF 規格，text segment 會由 virtual address 0x0804_8000 的地方開始 mapping，data segment 則是緊接在 text segment 之後。

另外，text segment 與 data segment 都是 PT_LOAD 類型，因此需要根據 Flg 欄位的屬性來知道該 segment 是 text segment 還是 data segment。詳見前一篇日記有關 segment permissions 的說明。

小結

總結本專欄到目前為止所得到的資訊如下。灰色部份是 interpreter 負責的工作，將在下篇日記討論。

請注意，本日記是針對 kernel 本身所做的 ELF loading 工作來做整理，即 kernel-space 的 program loading。另外一半的 program loading 是由 user-space 的 dynamic loader/linker 所完成，這裡所提的 dynamic loader/linker 就是我們不斷提到的 program interpreter。

• 2006.12.31: Process Creation, #1：由 shell 執行外部程式《基本觀念與範例》
• 2007.01.02: Process Creation, #2：Running a "User Process"

也請閱讀以下日記：

• 2007.01.05: Linux 的 Virtual Memory Areas（VMA）：基本概念介紹
• 2007.01.15: Linux 的 Virtual Memory Areas（VMA）：Process 與 VMA 整體觀念

Exec system call 的 service routine 'sys_execve' 主要的工作是「將外部程式（ELF image）取代掉原來的 process」，以 kernel 的角度來說，「原來的 process」就是 current。以下簡單分析 exec system call 重要關鍵，我們由 do_execve 函數看起。

do_execve 負責執行 sys_execve 的主要工作，在 do_execve 的工作流程中，我們不難發現，do_execve 最後會呼叫一個很重要的 API -  search_binary_handler()；在 search_binary_handler() API 裡，我們發現，此 API 會呼叫到 kernel space 的 ELF loader 來載入 ELF image 至 process memory。

Kernel 2.6 的 ELF loader 實作位於 load_elf_binary() ，此 API 實作於 fs/binfmt_elf.c 檔案。ELF loader 並非直接在前面所提到的 search_binary_handler() 裡呼叫。

ELF loader 與其它執行檔格式的 loader，是在 kernel 開機時，註冊至 kernel 裡：

static struct linux_binfmt elf_format = {
		.module		= THIS_MODULE,
		.load_binary	= load_elf_binary,
		.load_shlib	= load_elf_library,
		.core_dump	= elf_core_dump,
		.min_coredump	= ELF_EXEC_PAGESIZE
};

static int __init init_elf_binfmt(void)
{
	return register_binfmt(&elf_format);
}

當 exec system call 被叫用時，最終就會在  search_binary_handler() 裡 callback ELF loader 來載入 ELF image。

Kernel space 的 ELF loader

Kernel space 的 ELF loader 是以 segment 的觀念來讀取執行檔（ELF image），相關觀念請見以下日記：

• 2007.03.05: ELF 之 Program Loading 教學文件, #1: Segment 的觀念
• 2007.03.08: ELF 之 Program Loading 教學文件, #2: Program Header Table

load_elf_binary() 所做的工作有：

1. 讀取 ELF image 的 segment 資訊（由 program header table）。

2. 讀出 segment 內容。

3. 判斷是否有 program interpreter；若有，再讀取 program interpreter。

4. 將讀取到的 segment 內容取代掉 current 的內容，這個動作就是 exec system call 的重要特性。

Program interpreter 就是 dynamic loader/linker，即 /lib/ld-linux.so.2。Program interpreter 的作用是「loading shared libraries（dynamic linking）」。

我們看到 current 被外部（stored）的 ELF image 取代了，這是一個重要的里程碑，背後的意義是：ELF image 被載入到記憶體後，議題將由 ELF image 被帶入更高層次的主題 - Process Memory。

當 ELF image 成為 process memory 的形式後，就能開始研究 process memory、VMA 與 program execution（例如：scheduling）有關的議題了。

初次入門：一開始進行研究時，因為對於系統的基本觀念還不夠完備，因此「學中做、做中學」成了最有效率的入門方式，透過「概念的實作」與「實作讀到的概念」的過程，最可以幫助我們在短時間內掌握重要的核心知識。以 ELF 專欄為例，在入門時期，我用了 loader 0.1~0.5 共 5 個小範例來陳述 ELF 的格式以及 section 的觀念。

掌握觀念：首先發表一個自己的看法。「將所有理論或概念全部動手實作一遍」，在我看來，並不是很有效率的辦法，這種做法應當很有幫助，但是卻會延緩學習速度，因此，這個時 期的重點如果是在「通盤掌握整體的重要關鍵」，那麼「善用工具來做分析」自然是最有成 效的方式。以「工具來操作並驗證觀念」是建議的做法，另外一個理由是，這種做法比較能貼近實務面。在「ELF 之 Program Loading 教學文件」的日記裡，我將會以此做法來分享教學文件。

思考與研究：這個階段有點像是「實驗室」的做法，在這裡不再贅述。

Program Header Table

這裡有幾個重要的觀念：

1. Program header table 是程式要能執行的重要資訊，program header table 紀錄 ELF image 裡的 'segment' 分佈，請參考 Jollen's Blog「ELF 之 Program Loading 教學文件, #1: Segment 的觀念」的說明。

2. 對 dynamic loader/linker 來說，ELF 的 'section' 是通透性的（transparent），也就是在整個載入的過程裡，dynamic loader/linker 並不會知道他所載入的 'segment' 與實際的 section 有何關係。整個載入過程只讀取 program header table 所紀錄的 'segment'。

3. 也就是說，section header table 在此時期是用不到的，就算沒有 section header table 也不影響程式載入與執行；這個觀念可參考 Jollen's Blog「「Truncate It」小技倆的原始碼與原理」。

使用 readelf 來觀察執行檔的 program header table：

# readelf -l hello

Elf file type is EXEC (Executable file)
Entry point 0x8048278
There are 6 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x08048034 0x08048034 0x000c0 0x000c0 R E 0x4
  INTERP         0x0000f4 0x080480f4 0x080480f4 0x00013 0x00013 R   0x1
      [Requesting program interpreter: /lib/ld-linux.so.2]
  LOAD           0x000000 0x08048000 0x08048000 0x00408 0x00408 R E 0x1000
  LOAD           0x000408 0x08049408 0x08049408 0x00100 0x00104 RW  0x1000
  DYNAMIC        0x000414 0x08049414 0x08049414 0x000c8 0x000c8 RW  0x4
  NOTE           0x000108 0x08048108 0x08048108 0x00020 0x00020 R   0x4

 Section to Segment mapping:
  Segment Sections...
   00
   01     .interp
   02     .interp .note.ABI-tag .hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .rodata .eh_frame
   03     .data .dynamic .ctors .dtors .jcr .got .bss
   04     .dynamic
   05     .note.ABI-tag

Program header table 的 data structure 如下（/usr/include/elf.h）：

/* Program segment header.  */

typedef struct
{
  Elf32_Word    p_type;                 /* Segment type */
  Elf32_Off     p_offset;               /* Segment file offset */
  Elf32_Addr    p_vaddr;                /* Segment virtual address */
  Elf32_Addr    p_paddr;                /* Segment physical address */
  Elf32_Word    p_filesz;               /* Segment size in file */
  Elf32_Word    p_memsz;                /* Segment size in memory */
  Elf32_Word    p_flags;                /* Segment flags */
  Elf32_Word    p_align;                /* Segment alignment */
} Elf32_Phdr;

'readelf' 的列表與 program header table 的 data structure 相符，每個 field 所紀錄的資訊可參考註解說明，或是參照完整的 System V ABI 文件。

幾個重要資訊說明如下。

1. Segment 的個數與大小紀錄在 ELF 檔頭裡：

# readelf -h hello
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x8048278
  Start of program headers:          52 (bytes into file)
  Start of section headers:          1784 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         6
  Size of section headers:           40 (bytes)
  Number of section headers:         25
  Section header string table index: 24

2. Program header table 的 p_type 欄位必須先進行研究（/usr/include/elf.h）：

/* Legal values for p_type (segment type).  */

#define PT_NULL         0               /* Program header table entry unused */
#define PT_LOAD         1               /* Loadable program segment */
#define PT_DYNAMIC      2               /* Dynamic linking information */
#define PT_INTERP       3               /* Program interpreter */
#define PT_NOTE         4               /* Auxiliary information */
#define PT_SHLIB        5               /* Reserved */
#define PT_PHDR         6               /* Entry for header table itself */
#define PT_TLS          7               /* Thread-local storage segment */
#define PT_NUM          8               /* Number of defined types */
#define PT_LOOS         0x60000000      /* Start of OS-specific */
#define PT_GNU_EH_FRAME 0x6474e550      /* GCC .eh_frame_hdr segment */
#define PT_LOSUNW       0x6ffffffa
#define PT_SUNWBSS      0x6ffffffa      /* Sun Specific segment */
#define PT_SUNWSTACK    0x6ffffffb      /* Stack segment */
#define PT_HISUNW       0x6fffffff
#define PT_HIOS         0x6fffffff      /* End of OS-specific */
#define PT_LOPROC       0x70000000      /* Start of processor-specific */
#define PT_HIPROC       0x7fffffff      /* End of processor-specific */

標示紅色的部份是我們在 'readelf -l' 列表中所看到的 type。

3. p_flags 的意義也要先行了解（/usr/include/elf.h）：

/* Legal values for p_flags (segment flags).  */

#define PF_X            (1 << 0)        /* Segment is executable */
#define PF_W            (1 << 1)        /* Segment is writable */
#define PF_R            (1 << 2)        /* Segment is readable */
#define PF_MASKOS       0x0ff00000      /* OS-specific */
#define PF_MASKPROC     0xf0000000      /* Processor-specific */

Segment Permissions

Segment permission 是 p_flags 的組合，在 'readelf -l' 列表中則是相對應於 Flg 一欄。

Segment Contents

Segment 由哪些 section 所構成，同樣可由 'readelf -l' 列表的「Section to Segment mapping」部份觀察。

小結

以下表格整理目前為止所得到的結論。

下則日記將會針對 segment type 所討論。

我們知道 ld.so（dynamic linker/loader）與 ldd 指令，而這二個程式都會參考到 ELF 的 .dynstr（dynamic linking 的 string table）。以 ldd 來說，我們用 ldd 來找出 ELF 執行檔的相依動態程式庫：

# ldd hello
        libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

這個動作依賴 .dynstr 節區所提供的資訊，也就是說，當 .dynstr 的內容有誤或是不存在時，ld.so 與 ldd 便無法正常工作。例如：

# strip -R .dynstr hello
# ldd hello
./hello: ./hello: no version information available (required by ./hello)
# ./hello
./hello: ./hello: no version information available (required by ./hello)
./hello: relocation error: ./hello: symbol , version  not defined in file  with link time reference

另外再補充一點，在 .dynamic 節區裡的列表中，包含了一筆指向 .dynstr 節區的紀錄。使用簡單的工具操作此觀念如下：

# readelf  -S hello
...
Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .interp           PROGBITS        080480f4 0000f4 000013 00   A  0   0  1
  [ 2] .note.ABI-tag     NOTE            08048108 000108 000020 00   A  0   0  4
  [ 3] .hash             HASH            08048128 000128 000028 04   A  4   0  4
  [ 4] .dynsym           DYNSYM          08048150 000150 000050 10   A  5   1  4
  [ 5] .dynstr           STRTAB          080481a0 0001a0 00004c 00   A  0   0  1
  [ 6] .gnu.version      VERSYM          080481ec 0001ec 00000a 02   A  4   0  2
...

接著：

# readelf  -d hello

Dynamic segment at offset 0x414 contains 20 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000000c (INIT)                       0x8048230
 0x0000000d (FINI)                       0x80483d4
 0x00000004 (HASH)                       0x8048128
 0x00000005 (STRTAB)                     0x80481a0
 0x00000006 (SYMTAB)                     0x8048150
 0x0000000a (STRSZ)                      76 (bytes)
 0x0000000b (SYMENT)                     16 (bytes)
 0x00000015 (DEBUG)                      0x0
 0x00000003 (PLTGOT)                     0x80494f0
 0x00000002 (PLTRELSZ)                   16 (bytes)
 0x00000014 (PLTREL)                     REL
 0x00000017 (JMPREL)                     0x8048220
 0x00000011 (REL)                        0x8048218
 0x00000012 (RELSZ)                      8 (bytes)
 0x00000013 (RELENT)                     8 (bytes)
 0x6ffffffe (VERNEED)                    0x80481f8
 0x6fffffff (VERNEEDNUM)                 1
 0x6ffffff0 (VERSYM)                     0x80481ec
 0x00000000 (NULL)                       0x0

這裡的 "dynamic segment" 專指 ".dynamic" section，與上一篇日記提到的 "dynamic segment" 含義不同，特別一提，以避免混淆。

本系列日記「ELF 之 Program Loading 教學文件」將會介紹有關程式載入（program loading）的核心主題，在此之前，請先閱讀 Jollen 的「Executable and Linking Format」專欄，以基本基礎的先備知識。

Segments

由 "execution view" 的角度來看程式（即 process），所謂的節區（section）已經被進化成區段（segment）的觀念了。廣義來說，section 可被分為以下 3 種 segment：

• Text segment - 指存放唯讀（read-only）程式碼與資料的所有 section 。
• Data segment - 指存放可寫（writable data）程式碼與資料的所有 section。
• BSS segment - 即 .bss section。

另外，還有一類的 segment：

• Dynamic segment - 用來存放 dynamic linking 資訊的 section。

不過，當我們講到「process segment」時，指的是 text segment、data segment 與 BSS segment；process address space 就是由這三種 segment 所構成。

Text segment 是由以下的 section 組成：

• .text
• .rodata
• .hash
• .dynsym
• .dynstr
• .plt
• .rel.got

Data segment 是由以下的 section 組成：

• .data
• .dynamic
• .got
• .bss

依照 SystemV ABI 規格，我們看到 .bss section 被放到 data segment 裡，但嚴格來說，我們應把 .bss section 另外獨立出來討論。基本的 .bss section 觀念，可參考 Jollen 的「BSS Section Concepts」專欄。

此外，在 text segment 與 data segment 裡，包含了 4 個與 dynamic linking 有關的 section，整理如下圖。

與 dynamic linking 有關的 4 個 section 並非另外組成所謂的 dynamic segment，這只是我們在研究 dynamic linking 時邏輯上的用語。

到這裡，我們了解了一個相當重要的一個觀念：當程式載入後，是以 "segment" 的觀念存在於記憶體中，並且也是以 segment 的觀念被 Linux kernel 管理。ELF 執行檔被載入到記憶體的過程中，最重要的資訊就是前導專欄裡所提到的「Program Header Table」；就 ELF execution view 來說，program header table 是必要的，下篇日記會針對此議題做介紹。

• OpenMoko 釋出原始碼了

• OpenMoko 準備舉旗進攻了
• 「Mobile 2.0 的思考」與第一隻採用 OpenMoko 的 Linux Smartphone

OpenMoko 是史上頭一遭完全開放原始碼的 Linux 手機，OpenMoko 專案強調 100% 的開放與社群；隨著這個專案的正式問世，未來的 Linux mobile phone 生態想必將會出現大變化。以下是 OpenMoko announce 的 mail，為了見證這重要的歷史時刻，我將收到的 mailing-list 全文刊載：

日期: Wed, 14 Feb 2007 18:02:37 +0100   
寄件者: Harald Welte          
回給: contact@openmoko.org
收件者: announce@lists.openmoko.org
副本: community@lists.openmoko.org, openmoko-devel@lists.openmoko.org
主旨: [openmoko-announce] [ANNOUNCE] openmoko.org goes public
   
Hi! 

It is my pleasure to announce that as of now, we have opened public 
access to 

Our main portal: 
    http://www.openmoko.org/ 

Our public wiki: 
    http://wiki.openmoko.org/ 

Our subversion server: 
    http://svn.openmoko.org/ 
    http://svnweb.openmoko.org/ 

Our bugzilla: 
    http://bugzilla.openmoko.org/ 

Our 'developer file dump' 
    http://people.openmoko.org/ 

Our GForge installation 
    http://projects.openmoko.org/ 

Please also note that 
    http://lists.openmoko.org/ 
now has a number of more mailinglists.  To understand which list is used 
for what, I suggest reading 
https://wiki.openmoko.org/wiki/Development_resources#Mailing_Lists 

As indicated before, we are far from a finished end-user ready product. 

Also, please note, that given our current small team size, we will 
probably take quite a bit until we can respond to all your 
suggestions/comments and even contributions.  We hope for your 
understanding and patience. 

Cheers, 
-- 
- Harald Welte                        http://openmoko.org/ 
============================================================================ 
Software for the world's first truly open Free Software mobile phone 

OpenMoko 專案的第一支手機為 Neo1973，可以在 LinuxDevices.com 上的新聞看到他的實體照片 [Linux-powered iPhone killer available online in March]。OpenMoko & Neo1973 若推廣順利，想必許多 end-user 對這個專案的「崛起」可能會感到驚奇又不解。

OpenMoko 的成功與其重要性是可預見的，「宏觀」來看其致勝因素有：

• 1. 強調 open & community 的定位，而不是打著 Linux 手機的旗號在作戰。
• 2. OpenMoko 一開始就推出相當完整的社群工具（可參考 www.openmoko.org）。
• 3. Open source：端給社群愛好者的是很完整的 patch 與 application framework。
• 4. 從 OpenMoko 第一次 release project 開始，一直到目前實體產品快上市為止，幾近完美的 pre-ecosystem 建立手法與步驟，不但高明而且漂亮。

目前，在 OpenMoko 的 svn 可以找到 GSM 模組的 source code、GPRS 的 kernel patch、MMC/SD 的 kernel/U-Boot patch 與 GSM power management 的 Linux device driver 等。OpenMoko 端出了非常多的好東西給大家，並且也提供 OpenEmbedded 的 distribution 環境設定，真是感動了。

Sean，you're good！迎接 Mobile 2.0 世代的來臨。

2 個星期前釋出的 kernel v2.6.20 又多了許多功能與 device driver，詳細的 Changelog 說明可參考 kernelnewbies.org 的 [LinuxChanges]。此次的更新，幾個與我的工作較密切的有：

1. Linux 2.6.20 在 arch/powerpc/ 裡新增了 Sony Platstation 3 的支援。

2. Networking device driver 方面，更新了 Tsi 108/109 的 driver。Tsi 108/109 是 Tundra 的 north bridge for PowerPC 750 晶片。

3. 在 Workqueue API 方面也做了更新。

4. MMC 方面，加入了 high speed（50 Hz）SD card 的支援、v4 high speed mode 與 v4 wide-bus mode；另外，SDHCI high speed 的支援也加入了。

附帶一提，KVM 驅動程式果然也正式加入 Linux 2.6.20 了。

延伸閱讀

• 2007.01.31: Linux/PowerPC 新世代《序幕》
• 2006.12.12: Linux 2.6.20 將正式加入 KVM 驅動程式
• 2006.10.19: Kernel 2.6 的 KVM (Kernel Virtual Machine) 驅動程式來了
• 2006.11.02: KVM 驅動程式的 HOWTO
• 2006.12.06: 我要怎麼知道 kernel 更新了什麼東西？

# vi /etc/exports

/tftpboot *(ro,sync)

# /etc/rc.d/init.d/nfs start

$ sudo apt-get install nfs-server
$ sudo /etc/init.d/nfs-kernel-server start

# exportfs -a
# exportfs （做檢查）
/tftpboot <world>

# portmap
# mkdir /nfs
# mount -t nfs 10.1.36.4:/tftpboot /nfs

/home/rootfs *(rw,sync,no_root_squash)

# mkdir /nfs
# mount -t nfs 10.1.36.4:/home/rootfs /nfs
# chroot /nfs /bin/sh

/home/rootfs/bin *(ro,sync)
/home/rootfs/sbin *(ro,sync)

# mount -t nfs 10.1.36.4:/home/rootfs/bin /bin
# mount -t nfs 10.1.36.4:/home/rootfs/sbin /sbin

• arm9.so-busybox.tar.bz2
• arm9.so-hello.tar.bz2
• jk2410_pkgs_ports-20070204.tar.bz2

第一份是「bootstrap root filesystgem」的製作、第二份是 cross compile「Hello World」for ARM9 的實例、第三份是 madplay project 與 nano-X project（MP3 player 與 AVI player）的實例。

第一份範例的內容可參考 Jollen 的「製作 ARM9 的 Bootstrap Root Filesystem」教學文件，第二份範例與第三份範例的教學文件尚在調校中，未來也將會發表在 Jollen's Blog 與大家分享。良好的觀念，能得到組織結構較良好的實作，並且也會讓整個實作過程比較系統化；希望將我們上課的內容與大家分享。

Bootstrap root filesystem 的實作與觀念是 Embedded Linux 的基本功，建議同學們在建立基本觀念後，再反覆練習，直到熟練為止，才能得到最大學習成效！

要學習 dynamic loader 的議題，並深入核心實作，最好可以由 ld.so 程式設計的主題切入。ld.so 是 Linux 的 dynamic loader，如果 man ld.so 的話，可以得到以下解釋：

DESCRIPTION
       ld.so loads the shared libraries needed by a program, prepares the pro-
       gram to run, and then runs it.  Unless  explicitly  specified  via  the
       -static  option to ld during compilation, all Linux programs are incom-
       plete and require further linking at run time.

與 dynamic loader 有關的系統管理面議題如下，這些是基本功課，應先行了解：

• /etc/ld.so.conf（ld.so 的設定檔）
• ldconfig
• LD_LIBRARY_PATH

ld.so 其實就是我們所熟悉的 /lib/ld-linux.so.2 執行檔。至於 ld.so 的程式設計，則是由以下 3 個主要的函數切入：

#include <dlfcn.h>

void *dlopen(const char *filename, int flag); 
void *dlsym(void *handle, const char *symbol); 
int dlclose(void *handle); 

這個部份可以 'man dlopen'，便能得到非常詳盡的說明，同時還有一個範例程式。以下的範例是由 dlopen 的 man page 節錄出來的，我在裡頭加上了註解供您參考：

/* Filename: dl_call.c */
#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>

int main(void) 
{
    void *handle;	/* shared library 的 'handle' 指標 */
    double (*cosine)(double);   /* 指向 shared library 裡的函數 */
    char *error;	/* 記錄 dynamic loader 的錯誤訊息 */

    /* 開啟 shared library 'libm' */
    handle = dlopen ("libm.so", RTLD_LAZY);
    if (!handle) {
        fprintf (stderr, "%s\n", dlerror());
        exit(1);
    }

    dlerror();    /* Clear any existing error */

    /* 在 handle 指向的 shared library 裡找到 "cos" 函數,
     * 並傳回他的 memory address 
     */
    cosine = dlsym(handle, "cos");
    if ((error = dlerror()) != NULL)  {
        fprintf (stderr, "%s\n", error);
        exit(1);
    }

    /* indirect function call (函數指標呼叫),
     * 呼叫所指定的函數
     */
    printf ("%f\n", (*cosine)(2.0));
    dlclose(handle);
    return 0;
}

dlopen() 的 RTLD_LAZY 參數說明如下（節錄自 man page）：

RTLD_LAZY
    Perform lazy binding. Only resolve symbols as the code that references 
them is executed. If the symbol is never referenced, then it is never 
resolved. (Lazy binding is only performed for function references; references 
to variables are always immediately bound when the library is loaded.)

由於使用到 dlopen() 函數，編譯時請與 libdl 做連結：

$ gcc -o dl_call dl_call.c -ldl

以上的做法等於：

 printf ("%f\n", cos(2.0));

直接呼叫 libm 的函數時，則是與 libm 做連結：

$ gcc -o dl_call dl_call.c -lm

單純由程式設計的角度來看，利用 dlopen()+dlsym() 來「呼叫函數」與「直接呼叫函數」有什麼應用上的差異呢？事實上，libdl 的使用是很普遍的，許多軟體將自己的功能模組（modules）做成 shared library，並以 dlopen() 載入後使用，由於 shared library 是「可抽換」的，因此可透過 libdl 來做出「Plug-ins」這樣的功能。

基本觀念

需要由 user-space 讀取資料，或是寫入資料給 user-space 的主要 3 個 driver method 為：read、write 與 ioctl。指向 user-space 資料空間（buffer）的指標是 kernel 回呼 driver method 時所傳遞進來的，我們由 read、write 與 ioctl 的函數原型宣告來說明如何撰寫程式：

˙int card_ioctl(struct inode *inode, struct file *filp, unsigned int cmd, unsigned long arg);
˙ssize_t write(struct file *filp, const char *buff, size_t count, loff_t *offp);
˙ssize_t read(struct file *filp, char *buff, size_t count, loff_t *offp);

fops->ioctl 的參數 arg、fops->write 與 fops->read 的參數 buff 是指向 user-space 資料的指標。撰寫程式時，要注意資料型別上的不同。

實作 fops->ioctl

ioctl 代表 input/output control 的意思，故名思義，ioctl system call 是用來控制 I/O 讀寫用的，並且是支援user application存取裝置的重要 system call。因此，在 Linux 驅動程式設計上，我們會實作 ioctl system call 以提供 user application 讀寫（input/output）裝置的功能。

依此觀念，當 user application 需要將數字顯示到 debug card 時。範例 debug card 0.1.0 便需要實作 ioctl system call，然後在 fops->ioctl 裡呼叫 outb() 將 user application 所指定的數字輸出至 I/O port 80H。

User application 使用 GNU LIBC 的 ioctl() 函數呼叫 device driver 所提供的命令來「控制」裝置，因此驅動程式必須實作 fops->ioctl以提供「命令」給使用者。

fops->ioctl 函數原型如下：

int ioctl(struct inode *, struct file *, unsigned int, unsigned long);

Linux 驅動程式以一個唯一且不重覆的數字來代表 ioctl 的命令，設計 Linux 驅動程式時，我們必須使用 kernel 所提供的巨集來宣告命令。根據命令的「方向」，kernel 提供以下 4 個巨集供我們宣告 ioctl 命令：,

• _IO(type,nr)：表示此 ioctl 命令不指定資料向方
• _IOR(type,nr,dataitem)：此 ioctl 命令由裝置 (driver) 讀取資料
• _IOW(type,nr,dataitem)：此 ioctl 命令將資料寫入裝置
• _IOWR(type,nr,dataitem)：此 ioctl 命令同時讀寫資料

若 user application 呼叫到驅動程式未提供的命令，則回傳 -ENOTTY 錯誤代碼。

debug card 0.1.0 範例裡，我們宣告了一個 IOCTL_WRITE 命令，當 user application 呼叫此命令後，驅動程式會將 user application 所指定的數字顯示在 debug card 上。由於我們的資料方向為「寫入裝置」，因此使用的宣告巨集為 _IOW。

Debug card 0.1.0 實作 fops->ioctl 的完整程式片斷如下：

#include <linux/ioctl.h>

#define	DEV_MAJOR	121
#define	DEV_NAME	"debug"
#define  	DEV_IOCTLID	0xD0
#define	IOCTL_WRITE	_IOW(DEV_IOCTLID, 10, int)

unsigned long IOPort = 0x80;

void write_card(unsigned int);

void write_card(unsigned int num)
{
	outb((unsigned char)num, IOPort);
}

int card_ioctl(struct inode *inode, struct file *filp,
	  unsigned int cmd, unsigned long arg)
{
	switch (cmd) {
		case IOCTL_WRITE:
			write_card((unsigned int)arg);
			break;
		default:
			return -1;
	}
    	return 0;
}

struct file_operation 的定義並未列出，不過請別忘了在 fops 裡加上 ioctl system call 的欄位。

User-space

以 debug card 0.1.0 驅動程式為例，user-space 的測試程式寫法如下：

int main(int argc, char *argv[])
{
    int devfd;
    int num = 0;

    if (argc > 1) num = atoi(argv[1]);
    if (num < 0) num = 0xff;

    devfd = open("/dev/debug", O_RDONLY);
    if (devfd == -1) {
	printf("Can't open /dev/debug\n");
	return -1;
    }

    printf("Write 0x%02x...\n", num);
    ioctl(devfd, IOCTL_WRITE, num);
    printf("Done. Wait 5 seconds...\n");
    sleep(5);
    close(devfd);

    return 0;
}

# ls arch/powerpc/platforms/
4xx/ 85xx/ apus/ embedded6xx/ maple/ prep/
82xx/ 86xx/ cell/ iseries/ pasemi/ pseries/
83xx/ 8xx/ chrp/ Makefile powermac/

ENTRY(_start)
SECTIONS
{
        . = 0x00000000;

        . = ALIGN(4);
        .text      :
        {
          cpu/arm920t/start.o   (.text)
          *(.text)
        }

在 linker script 的 SECTIONS 命令區塊中，.text section 一開始被放進 <U-Boot>/cpu/arm920t/start.o 檔，所以能了解到此檔案是整個 U-Boot 程式的進入點。因此，「整體的 U-Boot 啟動流程，是由 <U-Boot>/cpu/arm920t/start.o 檔案開始的」，start.o 是 U-Boot for ARM9 整個程式碼中，唯一的 assembly code，其原始程式的檔名為 start.S。

所以，由 <U-Boot>/cpu/arm920t/start.S 開始研讀，是了解 U-Boot 整個執行過程的起始點。另外，附帶一提，就概念上來說，start.S 最主要的工作是：

• 設定中斷向量表
• 設定 processor
• Initialization Sequence
• Relocation

因此，我們把 start.S 也稱為「hardware bring-up code」，而且是「前期」的硬體帶動碼（bring-up code）。在 U-Boot 的 cpu/ 目錄下，可以看到 U-Boot 為各種不同的處理器所撰寫的 bring-up code，可見 U-Boot 真的是一個「萬用 bootloader」。

下篇日記，我將會分享 start.S 的研讀筆記，歡迎對 U-Boot 有興趣的朋友來信指教。

有這樣需要的幾個具體理由是：

• 練習 U-Boot 移植。

• 避免修改到原始的 BSP 程式碼。

• 門面問題，讓 U-Boot 也能有專屬於我們板子的支援，而不是基於其他的板子。

• 將來會正式釋出 patch。

以下是「Porting a New Board」的具體做法：

1. 產生 JK2410 的 BSP 專屬目錄。

# cd <U-Boot>

# cd board

# cp -pa smdk2410/ jk2410/

jk2410/ 目錄下的程式碼與 smdk2410/ 完全相同。

2. 建立專屬的 config 檔。

# cd <U-Boot>

# cd include/configs/

# cp smdk2410.h jk2410.h

基於 smdk2410.h 來產生我們專屬的 jk2410.h 設定檔。

3. 修改 Makefile，基於 SMDK2410 來加入 JK2410 的 rule，紅色部份是新加入的設定：

smdk2410_config :       unconfig
        @./mkconfig $(@:_config=) arm arm920t smdk2410 NULL s3c24x0

jk2410_config   :       unconfig
        @./mkconfig $(@:_config=) arm arm920t jk2410 NULL s3c24x0

紅色粗體字部份是板子的目錄名稱，即 <U-Boot>/board/<Board Name>。

專屬於 JK2410 的設定選項

完成後，我們就能以專屬的設定，將 U-Boot 設定為 JK2410 的支援：

# cd <U-Boot>

# make jk2410_config
Configuring for jk2410 board...

Let's start and happy porting !!

The collaboration of giants now known as the LiMo Foundation was first announced in mid-June of last year. The group's goals and official name remained a mystery until today,

- An API specification
- An architecture
- References to open source code
- New source code-based reference implementation components (to be developed and contributed by Foundation members)
- Specifications for referenced third party software

From a legal perspective, it appears that the LiMo Foundation will license its APIs to members on a royalty-free basis, using a "Foundation Public License" (FPL). Of course, the kernel and middleware defined by the Foundation's specifications will remain under open source licenses such as the GPL.

• 2007.01.22: OpenMoko 準備舉旗進攻了
• 2006.11.08: 「Mobile 2.0 的思考」與第一隻採用 OpenMoko 的 Linux Smartphone
• 2006.12.25: Hiker：另一個 GTK+ based 的 Linux mobile phone application framework

延伸閱讀

• 2006.10.03: Library Dependency 的議題要點

• 2006.11.08: 「Mobile 2.0 的思考」與第一隻採用 OpenMoko 的 Linux Smartphone
]]> https://www.jollen.org/blog/2007/01/openmoko_announce.html https://www.jollen.org/blog/2007/01/openmoko_announce.html Openmoko Mon, 22 Jan 2007 20:16:27 +0800 以下整理自 Jollen 筆記（非教學文件），許多地方未能清楚交待，這部份有請大家自行補齊了。本文分享給有志研究 Linux MMC 驅動程式實作（MMC Core）的朋友參考。以下分析基於 Linux 2.6.17.7，更新版本的 kernel 加入了許多 patch（例如 Linux 2.6.19 的 SDHC patch），這些更新內容不在討論之列。

續前一篇日記「Linux（open source）的 SD/MMC/SDIO 支援現況概要」所提到的，目前的 Linux SD/MMC/SDIO 「嚴格來說」，只支援 MMC 記憶卡，如果是要插上 SD 記憶卡，使用上則會有諸多限制。

由 Linux 驅動程式的角度來看，單就 MMC 的部份來分析的話，Linux 的 SD/MMC 驅動程式層包含以下實作（Kconfig）：

• CONFIG_MMC
• CONFIG_MMC_BLOCK

相關檔案位於 drivers/mmc/ 目錄，我們由 Makefile 來找到實作檔案：

#                                                       
# Core                                                  
#                                                       
obj-$(CONFIG_MMC)               += mmc_core.o           
                                                        
#                                                       
# Media drivers                                         
#                                                       
obj-$(CONFIG_MMC_BLOCK)         += mmc_block.o          
                                                        
#                                                       
# Host drivers                                          
#                                                       
obj-$(CONFIG_MMC_ARMMMCI)       += mmci.o               
obj-$(CONFIG_MMC_PXA)           += pxamci.o             
obj-$(CONFIG_MMC_IMX)           += imxmmc.o             
obj-$(CONFIG_MMC_SDHCI)         += sdhci.o              
obj-$(CONFIG_MMC_WBSD)          += wbsd.o               
obj-$(CONFIG_MMC_AU1X)          += au1xmmc.o            
obj-$(CONFIG_MMC_OMAP)          += omap.o               
obj-$(CONFIG_MMC_AT91RM9200)    += at91_mci.o           
                                                        
mmc_core-y := mmc.o mmc_queue.o mmc_sysfs.o             

Host controller 驅動程式的部份先不討論，MMC Core API 層的實作檔案整理如下：

1. drivers/mmc/mmc.c：主要的 MMC command 與 protocol 實作。
2. drivers/mmc/mmc_queue.c：I/O Request Queue 的實作。
3. drivers/mmc/mmc_sysfs.c：Linux 2.6 的 kobject 與 sysfs 實作。
4. drivers/mmc/mmc_block.c：區塊層架構實作，即 interface to user-space 的 file operation 部份。

由此可知，MMC Core 層包含以下原始程式碼：

• drivers/mmc/mmc.c
• drivers/mmc/mmc_queue.c
• drivers/mmc/mmc_sysfs.c

區塊層部份，mmc_block.c 以 devfs 的方式向 kernel 註冊：

static struct mmc_driver mmc_driver = {
	.drv		= {
		.name	= "mmcblk",
	},
	.probe		= mmc_blk_probe,
	.remove		= mmc_blk_remove,
	.suspend		= mmc_blk_suspend,
	.resume		= mmc_blk_resume,
};

static int __init mmc_blk_init(void)
{
	int res = -ENOMEM;

	res = register_blkdev(major, "mmc");
	if (res < 0) {
		printk(KERN_WARNING "Unable to get major %d for MMC media: %d\n",
		       major, res);
		goto out;
	}
	if (major == 0)
		major = res;

	devfs_mk_dir("mmc");
	return mmc_register_driver(&mmc_driver);

 out:
	return res;
}
...
module_init(mmc_blk_init);

mmc_register_driver() 向 MMC Core 層註冊，接著 MMC Core 再對 kobject 做註冊。學過 Linux 2.6 驅動程式的朋友都曉得，Core API 層必須呼叫 driver_register() 向 kobject 註冊為 Driver；對於底層（machine-dependent）的 host controller 驅動程式而言，則必須向 kobject 註冊為 Platform Driver。

由於 kobject 會 callback fops 的 probe method，所以 mmc_blk_probe() 函數就是 MMC 區塊層的進入點（entry point）。所以，MMC 區塊層的一切動作就要由 mmc_blk_probe() 函數看起。Linux 2.6.17.7 的 MMC 區塊層使用到大家所熟悉的 genhd.c 層。

至於 Linux 區塊層驅動程式最重要的「初始化 I/O request queue」動作，則是同樣在 mmc_blk_probe() 階段呼叫到 MMC Core 層的 mmc_init_queue() 來完成。

了解 Linux 的 MMC 整體架構後，便能開始深入研究「規格的實作」部份。

]]> https://www.jollen.org/blog/2007/01/linux_26_mmc_core.html https://www.jollen.org/blog/2007/01/linux_26_mmc_core.html Linux Device Drivers & Kernel Sat, 20 Jan 2007 00:06:38 +0800 SD（Secure Digital）與 MMC（Multimedia Card）

SD 是一種 flash memory card 的標準，也就是一般常見的 SD 記憶卡，而 MMC 則是較早的一種記憶卡標準，目前已經被 SD 標準所取代。在維基百科上有相當詳細的 SD/MMC 規格說明：[http://zh.wikipedia.org/wiki/Secure_Digital]。

SDIO（Secure Digital I/O）

SDIO 是目前我們比較關心的技術，SDIO 故名思義，就是 SD 的 I/O 介面（interface）的意思，不過這樣解釋可能還有點抽像。更具體的說明，SD 本來是記憶卡的標準，但是現在也可以把 SD 拿來插上一些週邊介面使用，這樣的技術便是 SDIO。

所以 SDIO 本身是一種相當單純的技術，透過 SD 的 I/O 接腳來連接外部週邊，並且透過 SD 上的 I/O 資料接位與這些週邊傳輸資料，而且 SD 協會會員也推出很完整的 SDIO stack 驅動程式，使得 SDIO 週邊（我們稱為 SDIO 卡）的開發與應用變得相當熱門。

現在已經有非常多的手機或是手持裝置都支援 SDIO 的功能（SD 標準原本就是針對 mobile device 而制定），而且許多 SDIO 週邊也都被開發出來，讓手機外接週邊更加容易，並且開發上更有彈性（不需要內建週邊）。目前常見的 SDIO 週邊（SDIO 卡）有：

• Wi-Fi card（無線網路卡）
• CMOS sensor card（照相模組）
• GPS card
• GSM/GPRS modem card
• Bluetooth card
• Radio/TV card（很好玩）

SDIO 的應用將是未來嵌入式系統最重要的介面技術之一，並且也會取代目前 GPIO 式的 SPI 介面。

SD/SDIO 的傳輸模式

SD 傳輸模式有以下 3 種：

• SPI mode（required）
• 1-bit mode
• 4-bit mode

SDIO 同樣也支援以上 3 種傳輸模式。依據 SD 標準，所有的 SD（記憶卡）與 SDIO（週邊）都必須支援 SPI mode，因此 SPI mode 是「required」。此外，早期的 MMC 卡（使用 SPI 傳輸）也能接到 SD 插糟（SD slot），並且使用 SPI mode 或 1-bit mode 來讀取。

SD 的 MMC Mode

SD 也能讀取 MMC 記憶體，雖然 MMC 標準上提到，MMC 記憶體不見得要支援 SPI mode（但是一定要支援 1-bit mode），但是市面上能看到的 MMC 卡其實都有支援 SPI mode。因此，我們可以把 SD 設定成 SPI mode 的傳輸方式來讀取 MMC 記憶卡。

SD 的 MMC Mode 就是用來讀取 MMC 卡的一種傳輸模式。不過，SD 的 MMC Mode 雖然也是使用 SPI mode，但其物理特性仍是有差異的：

• MMC 的 SPI mode 最大傳輸速率為 20 Mbit/s；
• SD 的 SPI mode 最大傳輸速率為 25 Mbit/s。

為避免混淆，有時也用 SPI/MMC mode 與 SPI/SD mode 的寫法來做清楚區別。

Linux 的 SD/MMC 驅動程式

Linux 2.6.17 正式加入 SD/MMC 驅動程式，「官方版」的 release 當然只能在 ARM 平臺上使用，若不討論 host controller 的支援，目前的 Linux SD/MMC/SDIO 支援狀況（Core API）如下（Open source compatible for SD/MMC/SDIO）：

1. 支援 MMC。Open source 的實作即是 SD-MMC 的驅動程式。

2. Core API 「可以做到」支援 SD/SPI mode only，因為有辦法做到支援 SPI mode，當然 1-bit mode 也「可以想辦法」做出來。將 1-bit mode 擴充至 4-bit mode，網路上雖然有人做，不過會有版權問題。

3. SDIO 目前只看到 Atheros Wi-Fi card 的支援（可在 sourceforge 上找到，已正式釋出 source code）。

4. 完整的 SD stack 是要付錢的，請特別注意，SD Card Association product license agreement 並「不」允許 open source 的驅動程式實作。所以也不用再問，為什麼沒有 open source 的 SD 驅動程式了；Linux 是無罪的！

請特別留意的是，以上所述是「官方」的正式支援，並不包含玩家所分享的各種 patch。

]]> https://www.jollen.org/blog/2007/01/open_source_sd_mmc_sdio.html https://www.jollen.org/blog/2007/01/open_source_sd_mmc_sdio.html 其它 Fri, 19 Jan 2007 17:32:39 +0800 Jinvani Systech 推出 SD/SDIO 的發展平臺，特別的是，這是一張 PCI-based 的 host controller 卡！相當的有用處，詳見 LinuxDevices.com 上的新聞全文 [http://www.linuxdevices.com/news/NS7542044278.html]。

我以「相當的有用處」來形容這個發展平臺的理由是，在 SD/SDIO 相關的專案裡頭，host controller 的發展與移植並非首要的工作，重點工作反而是：

1. 基於 SD/SDIO 週邊介面卡的 device driver，例如 WiFi card、Bluetooth、GPS modem、SD memory 等。

2. SD/SDIO card 的相關應用程式，例如數位相框軟體（基於 SD memory card）等。

因此，如果可以在 host 端（x86）插上一張這種卡，事情就美妙許多了，因為可以減化部份應用程式的測試工作，同時也能加速 SDIO device driver 的開發。以往，雖然寫的是單純的 SD/SDIO 應用程式，可是總是要做 target 端的實機測試，總覺得有點不方便；或是，無法在 host 端使用模擬平臺（例如：Qemu）來做驅動程式的測試，非得要丟上 target board 才有辦法實測，相當費力不說，也不方便除錯（debug）。

對於 Embedded Linux 的應用開發，這張 SD/SDIO 開發板確實很有幫助。以下是這張 SD/SDIO 開發板的規格（節錄自 LinuxDevices.com 新聞）：

• Supports two SD card slots
• SD memory and SDIO capable
• SD Host 1.0 compatible
• Supports high capacity / high speed SD memory cards
• Supports security commands
• Supports SD 1-bit and 4-bit modes (no SPI)
• Supports SD Sleuth II

此外，這張 SD/SDIO 開發板也支援 SD Memory 開機！

]]> https://www.jollen.org/blog/2007/01/sdsdio.html https://www.jollen.org/blog/2007/01/sdsdio.html Embedded Linux: Platforms and Applications Fri, 19 Jan 2007 15:49:48 +0800 本文是單純實作時的測試方法說明，「Bootstrap root filesystem」的做法、步驟、概念與隱含的觀念請自行參考相關文件。

前情提要：由 Busybox 開始

這個階段的實作「提要」如下。

我們到 Busybox 官方網站下載原始碼：http://busybox.net/downloads/busybox-1.3.1.tar.bz2。如果您是初次「把玩」open source package，必須了解一個重要的概念：對任何的 open source 套件而言，以下二份文件是必讀的：

• README

• INSTALL

大多數的套件都包含以上二個檔案，並且許多重要的資訊都寫在這二份文件檔裡。將 Busybox 套件解開後，先檢查以下的 utility 是否有勾選：

• init process

• shell（請優先選用 ash）

並且將安裝路徑（install prefix）設定到事先建立的 root filesystem 空目錄。接著進行編譯，在編譯過程中可能會產生一些錯誤，請先把產生錯誤的選項取消，試著將 Busybox 編譯出來後並安裝至 root filesystem 目錄下。

我要怎麼測試此階段 root filesystem 的正確性？

假設 root filesystem 放在 /tmp/busybox_project/rootfs 目錄下，那麼直接用 chroot 來做第一次測試是不錯的方式。指令如下：

$ chroot /tmp/busybox_project/rootfs/ /bin/sh

若出現以下訊息，表示此 root filesystem 是無法運作的：

chroot: /bin/sh: No such file or directory

以下是正確無誤的畫面：

# chroot /tmp/busybox_project/rootfs/ /bin/sh


BusyBox v1.3.1 (2007-01-17 14:42:55 CST) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

# ls
bin      lib      linuxrc  sbin     usr

進到 shell 模式後，就可以跑 root filesystem 裡的應用程式了。這種測試方式，主要是對 root filesystem 裡的應用程式進行執行測試，主要的目的可能有：

1. 了解 shell 與應用程式是否能正常執行。
2. 了解 library dependencies 的正確性。
3. 了解應用程式的執行結果是否正確。
4. 了解應用程式的設定檔是否正確設定。
5. Root filesystem 是否還缺少什麼元件（檔案、工具、設定檔等等）。

常見原因

此階段產生錯誤的原因可能有：

1. 缺少 shell。
2. library dependencies 問題。

這種測試方式，可能無法真正有效測試到 init process 階段的問題，因此變更 root 根目錄後的第一個執行程式應該指定為 shell。

如果您想練習 chroot 測試，必須下載 Busybox 並自行建構基本的 root filesystem。我也提供了此階段的成果檔案 [http://tw.jollen.org/root-filesystem/busybox_project_001.tar.bz2]，以方便您練習 chroot 用法。

]]> https://www.jollen.org/blog/2007/01/embedded_linux_testing_rfs.html https://www.jollen.org/blog/2007/01/embedded_linux_testing_rfs.html Embedded Linux: Platforms and Applications Wed, 17 Jan 2007 15:43:08 +0800 今天在討論基本的 shared memory 機制時聊到，shared memory 有同步性的問題（synchronization），主要的原因是 Linux 並未對 shared memory 做同步的控制。以下單純由 user-space programming 的角度來探討此觀念。

首先，試作以下 3 個小程式：

• shm_allocate.c，用來請求 shared memory

• shm_read.c，用來讀取 shared memory

• shm_write.c，用來寫入 shared memory

以上程式可由 [http://tw.jollen.org/ipc-programming/shm_race.tar.bz2] 下載。以下是操作方法：

# ./shm_allocate jollen
Shared Memory Segment ID: 98306

先執行 shm_allocate 配置 shared memory，並任意填入一個初始字串，程式會印出此 shared memory 的 Segment ID。接著：

# ./shm_read 98306
Message of Shared Memory: jollen
Message of Shared Memory: jollen
Message of Shared Memory: jollen
Message of Shared Memory: jollen
...

再執行 shm_read，命令列參數加上 shared memory 的 Segment ID。shm_read 會持續不斷的讀取 shared memory 的內容。然後，在另一個 terminal 執行 shared memory 的寫入程式。

我們透過 shm_write 寫入 [00000000,11111111,22222222,...,99999999] 字串到 shared memory，並觀察輸出。由於 shm_write 寫入 shared memory 的資料是「相同數字的字串」，因此，若觀察到以下的結果，表示 shm_read 與 shm_write 間存在 race condition 問題：

...
Message of Shared Memory: 98888888
Message of Shared Memory: 33333322
Message of Shared Memory: 11111111
Message of Shared Memory: 66666666
Message of Shared Memory: 44443333
Message of Shared Memory: 77777666
...

因此，使用 shared memory 做為 IPC 機制時，必須實作同步的演算法。由演算法層面來討論，我們區分以下 3 個層面的探討：

• All Read：不需考慮 race condition。

• 1-Write、n-Read（n >= 1）

• n-Write、n-Read（n >= 1）

可此可知，當「只有有人寫入 shared memory，便要考慮 race conditon 問題」。若由演算法層面來思考此問題，以下是相對較為單純簡單的做法：

• 1-Write、n-Read（n >= 1）：可使用 lock file 的機制。

• n-Write、n-Read（n >= 1）：lock file 若是以 polling 方式做 waiting，必須配合 queue（或 circular queue）來實作，才能真正有效解決問題。

有機會的話，再跟大家分享朋友寫的 code。

]]> https://www.jollen.org/blog/2007/01/shared_memory_race_condition.html https://www.jollen.org/blog/2007/01/shared_memory_race_condition.html GNU Toolchains & Linux Systems Programming Tue, 16 Jan 2007 15:54:34 +0800 要了解 VMA（Virtual Memory Area）的「整體觀念」，最好的方式就是圖解說明。下圖說明了 process 與 VMA 的整體觀念。


圖：Process 與 VMA 整體觀念

Memory Descriptor

Linux 的「Process Descriptor」資料結構為 struct task_struct（include/linux/sched.h）。Process descriptor 裡的 mm field 紀錄了 process 的 VMA 資訊：

struct task_struct {
	...
	struct mm_struct *mm;
	...
}

struct mm_struct 即是 Linux 提供的「Memory Descriptor」資料結構，以下是 struct mm_struct 的原型宣告：

struct mm_struct {
	struct vm_area_struct * mmap;	/* list of VMAs */
	struct rb_root mm_rb;
	struct vm_area_struct * mmap_cache;	/* last find_vma result */
	unsigned long (*get_unmapped_area) (struct file *filp,
				unsigned long addr, unsigned long len,
				unsigned long pgoff, unsigned long flags);
	void (*unmap_area) (struct mm_struct *mm, unsigned long addr);
	unsigned long mmap_base;		/* base of mmap area */
	unsigned long task_size;		/* size of task vm space */
	unsigned long cached_hole_size;      /* if non-zero, the largest hole below free_area_cache */
	unsigned long free_area_cache;	/* first hole of size cached_hole_size or larger */
	pgd_t * pgd;
	atomic_t mm_users;			/* How many users with user space? */
	atomic_t mm_count;			/* How many references to "struct mm_struct" (users count as 1) */
	int map_count;				/* number of VMAs */
	struct rw_semaphore mmap_sem;
	spinlock_t page_table_lock;		/* Protects page tables and some counters */

	struct list_head mmlist;		/* List of maybe swapped mm's.  These are globally strung
					 * together off init_mm.mmlist, and are protected
					 * by mmlist_lock
					 */

	/* Special counters, in some configurations protected by the
	 * page_table_lock, in other configurations by being atomic.
	 */
	mm_counter_t _file_rss;
	mm_counter_t _anon_rss;

	unsigned long hiwater_rss;	/* High-watermark of RSS usage */
	unsigned long hiwater_vm;	/* High-water virtual memory usage */

	unsigned long total_vm, locked_vm, shared_vm, exec_vm;
	unsigned long stack_vm, reserved_vm, def_flags, nr_ptes;
	unsigned long start_code, end_code, start_data, end_data;
	unsigned long start_brk, brk, start_stack;
	unsigned long arg_start, arg_end, env_start, env_end;

	unsigned long saved_auxv[AT_VECTOR_SIZE]; /* for /proc/PID/auxv */

	unsigned dumpable:2;
	cpumask_t cpu_vm_mask;

	/* Architecture-specific MM context */
	mm_context_t context;

	/* Token based thrashing protection. */
	unsigned long swap_token_time;
	char recent_pagein;

	/* coredumping support */
	int core_waiters;
	struct completion *core_startup_done, core_done;

	/* aio bits */
	rwlock_t		ioctx_list_lock;
	struct kioctx		*ioctx_list;
};

Memory descriptor 故名思義，是用來描述 process 記憶體資訊的資料結構。由 struct mm_struct 裡可以看到一個稱為 mmap 的 field，mmap 的 data type 為 struct vm_area_struct，這個資料結構即是我們在「Linux 的 Virtual Memory Areas（VMA）：基本概念介紹」所介紹的 VMA 資料結構。

VMA 與 ELF Image 的對映關係

在「Linux 的 Virtual Memory Areas（VMA）：基本概念介紹」曾經介紹過，Process 的 VMA 對映，可以由 /proc/<pid>/maps 檔案查詢；例如 pid 1（init）的 VMA mapping 為：

$ cat /proc/1/maps
08048000-0804e000 r-xp 00000000 08:01 12118      /sbin/init
0804e000-08050000 rw-p 00005000 08:01 12118      /sbin/init
08050000-08054000 rwxp 00000000 00:00 0
40000000-40016000 r-xp 00000000 08:01 52297      /lib/ld-2.2.4.so
40016000-40017000 rw-p 00015000 08:01 52297      /lib/ld-2.2.4.so
40024000-40025000 rw-p 00000000 00:00 0
40025000-40157000 r-xp 00000000 08:01 58241      /lib/i686/libc-2.2.4.so
40157000-4015c000 rw-p 00131000 08:01 58241      /lib/i686/libc-2.2.4.so
4015c000-40160000 rw-p 00000000 00:00 0
bfffe000-c0000000 rwxp fffff000 00:00 0　

列表結果便能用來說明 VMA 與 ELF image 之間的關係。搭配上圖來說明列表結果的 VMA 對映關係，如下：

1. 第 1 列（row）是 ELF 執行檔（/sbin/init）的 code section VMA mapping；
2. 第 2 列是 ELF 執行檔的 data section VMA mapping；
3. 第 3 列是 ELF 執行檔的 .bss section VMA mapping。
4. 第 4 列是 dynamic loader（/lib/ld-2.2.4.so）的 code section VMA mapping；
5. 第 5 列是 dynamic loader 的 data section VMA mapping；
6. 第 6 列是 dynamic loader 的 .bss section VMA mapping。
7. 第 7 列是 libc 的 code section VMA mapping；
8. 第 8 列是 libc 的 data section VMA mapping；
9. 第 9 列是 libc 的 .bss section VMA mapping。

另外，要留意的是，在文中所指的 code section 與 data section 不見得就是 ELF 的 .text section 與 .data section；我們以 code section 來表示所有可執行的節區，以 data section 來表示包含資料的節區。

在整個 VMA 的討論過程中，我們只針對 code section 與 data section 做討論（如圖），至於 .bss section 的話，原則上另案來討論其核心實作會比較實際一些。

Also See

2007.01.05: Linux 的 Virtual Memory Areas（VMA）：基本概念介紹

]]> https://www.jollen.org/blog/2007/01/process_vma.html https://www.jollen.org/blog/2007/01/process_vma.html Linux Device Drivers & Kernel Mon, 15 Jan 2007 15:27:18 +0800 Before We Start

Trace Linux kernel 時，有幾個相當重要的原則要掌握住：

1. 不要對 Linux kernel 做逐行的研讀（trace line-by-line、最忌諱的做法），而是掌握我們想要了解的核心觀念，並針對此核心觀念來了解相關的實作細節。
2. 必須整理觀念與程式碼的對應，但並不是要大家對原始碼做逐行註解，而是針對細部觀念，將相關的實作片斷整理出來即可。
3. 每個 kernel API 的實作原本就會包含許多的「OS 基礎概念與理論」，例如：mutex、semaphore、locking 等等。與這些基礎知識相關的程式碼，本來就是屬於整體的部份，所以應該「跳脫」個別的 kernel API 實作。
4. 如 3.，也就是說，如果我原本就懂這些東西，就應該很清楚了解這些「片段程式碼」的作用，應避免「完美主意」作祟：不要急於看懂這些片斷的程式細節，以免因小失大。
5. 如 3.，如果我原本就不懂這些東西，可以試著把這些程式碼當做「黑盒子」來看待。這樣的，這也是「學習方法」的問題，並非要刻意逃避這些自己不懂的東西。

以本日記為例，我們想要了解 Linux kernel 如何產生新的 process，而其中的關鍵便是 copy_process() 函數。但是，目前我們在做的是 sys_fork() 的 trace，而 sys_fork() 並不指定任何的 clone_flags 參數值，因此，在 trace copy_process() 的過程中，我們可以先行略過與 clone_flags 有關的特定處理。

copy_process()

以下是 copy_process() 的完整實作，我把現階段可略過的部份標示為灰體字。

/*
 * This creates a new process as a copy of the old one,
 * but does not actually start it yet.
 *
 * It copies the registers, and all the appropriate
 * parts of the process environment (as per the clone
 * flags). The actual kick-off is left to the caller.
 */
static task_t *copy_process(unsigned long clone_flags,
				 unsigned long stack_start,
				 struct pt_regs *regs,
				 unsigned long stack_size,
				 int __user *parent_tidptr,
				 int __user *child_tidptr,
				 int pid)
{
	int retval;
	struct task_struct *p = NULL;

	if ((clone_flags & (CLONE_NEWNS|CLONE_FS)) == (CLONE_NEWNS|CLONE_FS))
		return ERR_PTR(-EINVAL);

	/*
	 * Thread groups must share signals as well, and detached threads
	 * can only be started up within the thread group.
	 */
	if ((clone_flags & CLONE_THREAD) && !(clone_flags & CLONE_SIGHAND))
		return ERR_PTR(-EINVAL);

	/*
	 * Shared signal handlers imply shared VM. By way of the above,
	 * thread groups also imply shared VM. Blocking this case allows
	 * for various simplifications in other code.
	 */
	if ((clone_flags & CLONE_SIGHAND) && !(clone_flags & CLONE_VM))
		return ERR_PTR(-EINVAL);

	retval = security_task_create(clone_flags);
	if (retval)
		goto fork_out;

	retval = -ENOMEM;
	p = dup_task_struct(current);
	if (!p)
		goto fork_out;

	retval = -EAGAIN;
	if (atomic_read(&p->user->processes) >=
			p->signal->rlim[RLIMIT_NPROC].rlim_cur) {
		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_SYS_RESOURCE) &&
				p->user != &root_user)
			goto bad_fork_free;
	}

	atomic_inc(&p->user->__count);
	atomic_inc(&p->user->processes);
	get_group_info(p->group_info);

	/*
	 * If multiple threads are within copy_process(), then this check
	 * triggers too late. This doesn't hurt, the check is only there
	 * to stop root fork bombs.
	 */
	if (nr_threads >= max_threads)
		goto bad_fork_cleanup_count;

	if (!try_module_get(task_thread_info(p)->exec_domain->module))
		goto bad_fork_cleanup_count;

	if (p->binfmt && !try_module_get(p->binfmt->module))
		goto bad_fork_cleanup_put_domain;

	p->did_exec = 0;
	copy_flags(clone_flags, p);
	p->pid = pid;
	retval = -EFAULT;
	if (clone_flags & CLONE_PARENT_SETTID)
		if (put_user(p->pid, parent_tidptr))
			goto bad_fork_cleanup;

	p->proc_dentry = NULL;

	INIT_LIST_HEAD(&p->children);
	INIT_LIST_HEAD(&p->sibling);
	p->vfork_done = NULL;
	spin_lock_init(&p->alloc_lock);
	spin_lock_init(&p->proc_lock);

	clear_tsk_thread_flag(p, TIF_SIGPENDING);
	init_sigpending(&p->pending);

	p->utime = cputime_zero;
	p->stime = cputime_zero;
 	p->sched_time = 0;
	p->rchar = 0;		/* I/O counter: bytes read */
	p->wchar = 0;		/* I/O counter: bytes written */
	p->syscr = 0;		/* I/O counter: read syscalls */
	p->syscw = 0;		/* I/O counter: write syscalls */
	acct_clear_integrals(p);

 	p->it_virt_expires = cputime_zero;
	p->it_prof_expires = cputime_zero;
 	p->it_sched_expires = 0;
 	INIT_LIST_HEAD(&p->cpu_timers[0]);
 	INIT_LIST_HEAD(&p->cpu_timers[1]);
 	INIT_LIST_HEAD(&p->cpu_timers[2]);

	p->lock_depth = -1;		/* -1 = no lock */
	do_posix_clock_monotonic_gettime(&p->start_time);
	p->security = NULL;
	p->io_context = NULL;
	p->io_wait = NULL;
	p->audit_context = NULL;
	cpuset_fork(p);
#ifdef CONFIG_NUMA
 	p->mempolicy = mpol_copy(p->mempolicy);
 	if (IS_ERR(p->mempolicy)) {
 		retval = PTR_ERR(p->mempolicy);
 		p->mempolicy = NULL;
 		goto bad_fork_cleanup_cpuset;
 	}
	mpol_fix_fork_child_flag(p);
#endif

#ifdef CONFIG_DEBUG_MUTEXES
	p->blocked_on = NULL; /* not blocked yet */
#endif

	p->tgid = p->pid;
	if (clone_flags & CLONE_THREAD)
		p->tgid = current->tgid;

	if ((retval = security_task_alloc(p)))
		goto bad_fork_cleanup_policy;
	if ((retval = audit_alloc(p)))
		goto bad_fork_cleanup_security;
	/* copy all the process information */
	if ((retval = copy_semundo(clone_flags, p)))
		goto bad_fork_cleanup_audit;
	if ((retval = copy_files(clone_flags, p)))
		goto bad_fork_cleanup_semundo;
	if ((retval = copy_fs(clone_flags, p)))
		goto bad_fork_cleanup_files;
	if ((retval = copy_sighand(clone_flags, p)))
		goto bad_fork_cleanup_fs;
	if ((retval = copy_signal(clone_flags, p)))
		goto bad_fork_cleanup_sighand;
	if ((retval = copy_mm(clone_flags, p)))
		goto bad_fork_cleanup_signal;
	if ((retval = copy_keys(clone_flags, p)))
		goto bad_fork_cleanup_mm;
	if ((retval = copy_namespace(clone_flags, p)))
		goto bad_fork_cleanup_keys;
	retval = copy_thread(0, clone_flags, stack_start, stack_size, p, regs);
	if (retval)
		goto bad_fork_cleanup_namespace;

	p->set_child_tid = (clone_flags & CLONE_CHILD_SETTID) ? child_tidptr : NULL;
	/*
	 * Clear TID on mm_release()?
	 */
	p->clear_child_tid = (clone_flags & CLONE_CHILD_CLEARTID) ? child_tidptr: NULL;
	p->robust_list = NULL;
#ifdef CONFIG_COMPAT
	p->compat_robust_list = NULL;
#endif
	/*
	 * sigaltstack should be cleared when sharing the same VM
	 */
	if ((clone_flags & (CLONE_VM|CLONE_VFORK)) == CLONE_VM)
		p->sas_ss_sp = p->sas_ss_size = 0;

	/*
	 * Syscall tracing should be turned off in the child regardless
	 * of CLONE_PTRACE.
	 */
	clear_tsk_thread_flag(p, TIF_SYSCALL_TRACE);
#ifdef TIF_SYSCALL_EMU
	clear_tsk_thread_flag(p, TIF_SYSCALL_EMU);
#endif

	/* Our parent execution domain becomes current domain
	   These must match for thread signalling to apply */
	   
	p->parent_exec_id = p->self_exec_id;

	/* ok, now we should be set up.. */
	p->exit_signal = (clone_flags & CLONE_THREAD) ? -1 : (clone_flags & CSIGNAL);
	p->pdeath_signal = 0;
	p->exit_state = 0;

	/*
	 * Ok, make it visible to the rest of the system.
	 * We dont wake it up yet.
	 */
	p->group_leader = p;
	INIT_LIST_HEAD(&p->thread_group);
	INIT_LIST_HEAD(&p->ptrace_children);
	INIT_LIST_HEAD(&p->ptrace_list);

	/* Perform scheduler related setup. Assign this task to a CPU. */
	sched_fork(p, clone_flags);

	/* Need tasklist lock for parent etc handling! */
	write_lock_irq(&tasklist_lock);

	/*
	 * The task hasn't been attached yet, so its cpus_allowed mask will
	 * not be changed, nor will its assigned CPU.
	 *
	 * The cpus_allowed mask of the parent may have changed after it was
	 * copied first time - so re-copy it here, then check the child's CPU
	 * to ensure it is on a valid CPU (and if not, just force it back to
	 * parent's CPU). This avoids alot of nasty races.
	 */
	p->cpus_allowed = current->cpus_allowed;
	if (unlikely(!cpu_isset(task_cpu(p), p->cpus_allowed) ||
			!cpu_online(task_cpu(p))))
		set_task_cpu(p, smp_processor_id());

	/* CLONE_PARENT re-uses the old parent */
	if (clone_flags & (CLONE_PARENT|CLONE_THREAD))
		p->real_parent = current->real_parent;
	else
		p->real_parent = current;
	p->parent = p->real_parent;

	spin_lock(¤t->sighand->siglock);

	/*
	 * Process group and session signals need to be delivered to just the
	 * parent before the fork or both the parent and the child after the
	 * fork. Restart if a signal comes in before we add the new process to
	 * it's process group.
	 * A fatal signal pending means that current will exit, so the new
	 * thread can't slip out of an OOM kill (or normal SIGKILL).
 	 */
 	recalc_sigpending();
	if (signal_pending(current)) {
		spin_unlock(¤t->sighand->siglock);
		write_unlock_irq(&tasklist_lock);
		retval = -ERESTARTNOINTR;
		goto bad_fork_cleanup_namespace;
	}

	if (clone_flags & CLONE_THREAD) {
		/*
		 * Important: if an exit-all has been started then
		 * do not create this new thread - the whole thread
		 * group is supposed to exit anyway.
		 */
		if (current->signal->flags & SIGNAL_GROUP_EXIT) {
			spin_unlock(¤t->sighand->siglock);
			write_unlock_irq(&tasklist_lock);
			retval = -EAGAIN;
			goto bad_fork_cleanup_namespace;
		}

		p->group_leader = current->group_leader;
		list_add_tail_rcu(&p->thread_group, &p->group_leader->thread_group);

		if (!cputime_eq(current->signal->it_virt_expires,
				cputime_zero) ||
		    !cputime_eq(current->signal->it_prof_expires,
				cputime_zero) ||
		    current->signal->rlim[RLIMIT_CPU].rlim_cur != RLIM_INFINITY ||
		    !list_empty(¤t->signal->cpu_timers[0]) ||
		    !list_empty(¤t->signal->cpu_timers[1]) ||
		    !list_empty(¤t->signal->cpu_timers[2])) {
			/*
			 * Have child wake up on its first tick to check
			 * for process CPU timers.
			 */
			p->it_prof_expires = jiffies_to_cputime(1);
		}
	}

	/*
	 * inherit ioprio
	 */
	p->ioprio = current->ioprio;

	if (likely(p->pid)) {
		add_parent(p);
		if (unlikely(p->ptrace & PT_PTRACED))
			__ptrace_link(p, current->parent);

		if (thread_group_leader(p)) {
			p->signal->tty = current->signal->tty;
			p->signal->pgrp = process_group(current);
			p->signal->session = current->signal->session;
			attach_pid(p, PIDTYPE_PGID, process_group(p));
			attach_pid(p, PIDTYPE_SID, p->signal->session);

			list_add_tail_rcu(&p->tasks, &init_task.tasks);
			__get_cpu_var(process_counts)++;
		}
		attach_pid(p, PIDTYPE_PID, p->pid);
		nr_threads++;
	}

	total_forks++;
	spin_unlock(¤t->sighand->siglock);
	write_unlock_irq(&tasklist_lock);
	proc_fork_connector(p);
	return p;

bad_fork_cleanup_namespace:
	exit_namespace(p);
bad_fork_cleanup_keys:
	exit_keys(p);
bad_fork_cleanup_mm:
	if (p->mm)
		mmput(p->mm);
bad_fork_cleanup_signal:
	cleanup_signal(p);
bad_fork_cleanup_sighand:
	__cleanup_sighand(p->sighand);
bad_fork_cleanup_fs:
	exit_fs(p); /* blocking */
bad_fork_cleanup_files:
	exit_files(p); /* blocking */
bad_fork_cleanup_semundo:
	exit_sem(p);
bad_fork_cleanup_audit:
	audit_free(p);
bad_fork_cleanup_security:
	security_task_free(p);
bad_fork_cleanup_policy:
#ifdef CONFIG_NUMA
	mpol_free(p->mempolicy);
bad_fork_cleanup_cpuset:
#endif
	cpuset_exit(p);
bad_fork_cleanup:
	if (p->binfmt)
		module_put(p->binfmt->module);
bad_fork_cleanup_put_domain:
	module_put(task_thread_info(p)->exec_domain->module);
bad_fork_cleanup_count:
	put_group_info(p->group_info);
	atomic_dec(&p->user->processes);
	free_uid(p->user);
bad_fork_free:
	free_task(p);
fork_out:
	return ERR_PTR(retval);
}

有許多沒有標成灰色字體的程式片斷，其實也應該先行省略不看，像是：資料結構的操作、spinlock、錯誤處理、變數初始化等等。

copy_process() 的關鍵在哪裡？

Trace 到這裡後，我會先就程式碼本身的實作，節錄「深入 sys_fork() 底層」相關的實作片斷。以下供您參考：

1. 新的 process description：

	struct task_struct *p = NULL;

2. "dup" current 成為 p：

	p = dup_task_struct(current);
	if (!p)
		goto fork_out;

3. copy_process() 會判斷目前的 process 數是否過多：

	if (nr_threads >= max_threads)
		goto bad_fork_cleanup_count;

max_threads 是在 fork_init() 階段算出來的，可參考「Jollen 的 Linux 核心分享包,#3: fork_init()《講義6》」。

4. 開始 "copy" current 給新的 process：

	if ((retval = copy_semundo(clone_flags, p)))
		goto bad_fork_cleanup_audit;
	if ((retval = copy_files(clone_flags, p)))
		goto bad_fork_cleanup_semundo;
	if ((retval = copy_fs(clone_flags, p)))
		goto bad_fork_cleanup_files;
	if ((retval = copy_sighand(clone_flags, p)))
		goto bad_fork_cleanup_fs;
	if ((retval = copy_signal(clone_flags, p)))
		goto bad_fork_cleanup_sighand;
	if ((retval = copy_mm(clone_flags, p)))
		goto bad_fork_cleanup_signal;
	if ((retval = copy_keys(clone_flags, p)))
		goto bad_fork_cleanup_mm;
	if ((retval = copy_namespace(clone_flags, p)))
		goto bad_fork_cleanup_keys;
	retval = copy_thread(0, clone_flags, stack_start, stack_size, p, regs);
	if (retval)
		goto bad_fork_cleanup_namespace;

作業還沒完

解析出精華的目的，當然是為了做「更深入」且「有效率」的研究。我用我的學習方法，呈現「Process Creation」系列專欄的推導過程；希望我的做法對您是真正有幫助的。

在繼續進行前，必須了解幾個基礎知識。Keyword 如下：

• process relationship
• process descriptor
• memory descriptor

「Process Creation」系列專欄到此告一段落，不過「作業」仍會完成，並不是就此結束。我會起另外一個專欄，來把剩下的 hacking 功課完成。

Also See

2007.01.11: Process Creation, #4：sys_fork《核心實作》 2007.01.08: Process Creation, #3：sys_fork《基本觀念》 2007.01.02: Process Creation, #2：Running a "User Process" 2006.12.31: Process Creation, #1：由 shell 執行外部程式《基本觀念與範例》

]]> https://www.jollen.org/blog/2007/01/process_creation_5_copy_process.html https://www.jollen.org/blog/2007/01/process_creation_5_copy_process.html Linux Device Drivers & Kernel Sun, 14 Jan 2007 01:59:19 +0800 wm.c 以 image.c 為範本，wm.c 執行後在畫面上只會看到圖片圖（沒有視窗標題列與邊框），並且可使用滑鼠來拖曳圖片。本範例主要在展示以下的 Nano-X API 程式設計方法：

˙ 如何設定視窗屬性（window manager）。
˙ 如何與使用者做互動（human interactive）。

要寫出「托曳圖片」的功能，首先必須把視窗的標題列與邊框去除，否則只能在標題列上托曳整個「視窗」。做法非常簡單，只要在建立視窗時設定 window manager 即可：

   wid = GrNewWindowEx(GR_WM_PROPS_APPWINDOW | 
                       GR_WM_PROPS_NODECORATE | 
                       GR_WM_PROPS_NOAUTOMOVE,
                       NULL,
                       GR_ROOT_WINDOW_ID, 
                       0, 0, 
                       image_jollen.width, /* 圖片寬度 */
                       image_jollen.height /* 圖片高度 */, 
                       0xFFFFFF);

粗體字的地方是新加入的 window manager 屬性，為了達到我們的要求，我們指定了3個屬性值：

• GR_WM_PROPS_APPWINDOW：使用 window manager 的外觀。
• GR_WM_PROPS_NODECORATE：不要有視窗邊框。
• GR_WM_PROPS_NOAUTOMOVE：第一次顯示視窗時不移動視窗。

由於我們並未指定 GR_WM_PROPS_CAPTION，因此不會有視窗標題列。 在處理使用者互動上，我們需要自行處理3個滑鼠事件：

• GR_EVENT_MASK_MOUSE_POSITION：滑鼠移動事件。
• GR_EVENT_MASK_BUTTON_UP：放開滑鼠按鍵。
• GR_EVENT_MASK_BUTTON_DOWN：按下滑鼠按鍵。

因此選擇事件的程式碼應修改成：

   GrSelectEvents(wid, GR_EVENT_MASK_MOUSE_POSITION | 
                           GR_EVENT_MASK_BUTTON_UP |
                           GR_EVENT_MASK_BUTTON_DOWN);

接下來，要特別注意的地方是「顯示圖片的時機」。我們在這裡設計成在視窗顯示後、進入 event loop 前處理。首先是顯示圖片的程式寫法：

   GrMapWindow(wid);
   GrDrawImageBits(wid, gc, 0, 0, &image_jollen);

接著，修改 event loop，並加上處理以上 3 個事件（粗體字部份）的程式碼：

void event_handler (GR_EVENT *event)
{
   switch (event->type)
   {
      case GR_EVENT_TYPE_CLOSE_REQ: 
            GrClose();
      case GR_EVENT_TYPE_MOUSE_POSITION:
            position_event(&event->mouse);
            break;
      case GR_EVENT_TYPE_BUTTON_UP:
      case GR_EVENT_TYPE_BUTTON_DOWN:
            button_event(&event->button);
            break;
      default: break;
   }
}

對於滑鼠按鍵的處理方式為：當滑鼠被按下時，便記錄滑鼠的新座標，然後將視窗移到最上層；若此時使用者移動滑鼠，則將整個「視窗」移到新座標位置。如此一來，使用者就會看到 「整個圖片被托曳」的效果。

處理滑鼠按鍵的程式寫法如下：

void button_event(GR_EVENT_BUTTON *e)
{
   if (e->type == GR_EVENT_TYPE_BUTTON_DOWN) {
      newx = e->x;
      newy = e->y;

      button_down = 1;
      GrRaiseWindow(e->wid);
   } else {
      button_down = 0;
   }
}

先判斷目前所產生的事件是否為 GR_EVENT_TYPE_BUTTON_DOWN；如果是，才記錄新座標，並將 button_down 設為 1。若不是 GR_EVENT_TYPE_BUTTON_DOWN 事件，表示滑鼠按鍵已放開，此時將 button_down 設為 0。
處理滑鼠移動事件的程式寫法如下：

void position_event(GR_EVENT_MOUSE *e)
{
   if (!button_down) return;

   GrMoveWindow(e->wid, e->rootx-newx, e->rooty-newy);
}

先判斷 button_down 是否為 false，若 button_down等於0，表示滑鼠按鍵是放開的，因此不做任何動作。反正，若 button_down 為true，代表滑鼠按鍵仍「持續」按住，此時才能呼叫 GrMoveWindow() 移動視窗。

以下是 wm.c 的完整程式，粗體字是新加入或修改過的程式碼。

/*
 * Copyright(c) 2003,2004 www.jollen.org
 *
 * - Nano-X API example.
 * - wm.c
 *
 */

#include <stdio.h>
#define MWINCLUDECOLORS
#include <microwin/nano-X.h>
#include <microwin/nxcolors.h>

GR_WINDOW_ID wid;
GR_GC_ID gc;

/* 外部影像 */
extern GR_IMAGE_HDR image_jollen;

void event_handler (GR_EVENT *event);

/* 滑鼠座標 */
int newx, newy;
int button_down;

int main (void)
{
   if (GrOpen() < 0) {
        fprintf (stderr, "GrOpen failed");
        return -1;
   }

   gc = GrNewGC();
   GrSetGCForeground (gc, 0xFF0000);

   wid = GrNewWindowEx(GR_WM_PROPS_APPWINDOW |
                       GR_WM_PROPS_NODECORATE | 
                       GR_WM_PROPS_NOAUTOMOVE,
                       NULL,
                       GR_ROOT_WINDOW_ID, 
                       0, 0, 
                       image_jollen.width, /* 影像寬度 */
                       image_jollen.height /* 影像高度 */, 
                       0xFFFFFF);

   GrSelectEvents(wid, GR_EVENT_MASK_MOUSE_POSITION |
                    GR_EVENT_MASK_BUTTON_UP |
                    GR_EVENT_MASK_BUTTON_DOWN);

   GrMapWindow(wid);
   GrDrawImageBits(wid, gc, 0, 0, &image_jollen);

   GrMainLoop(event_handler);

   return 0;
}

void button_event(GR_EVENT_BUTTON *e)
{
   if (e->type == GR_EVENT_TYPE_BUTTON_DOWN) {
      newx = e->x;
      newy = e->y;

      button_down = 1;
      GrRaiseWindow(e->wid);
   } else {
      button_down = 0;
   }
}

void position_event(GR_EVENT_MOUSE *e)
{
   if (!button_down) return;

   GrMoveWindow(e->wid, e->rootx-newx, e->rooty-newy);
}

void event_handler (GR_EVENT *event)
{
   switch (event->type)
   {
      case GR_EVENT_TYPE_CLOSE_REQ: 
	   GrClose();
      case GR_EVENT_TYPE_MOUSE_POSITION:
	   position_event(&event->mouse);
	   break;
      case GR_EVENT_TYPE_BUTTON_UP:
      case GR_EVENT_TYPE_BUTTON_DOWN:
           button_event(&event->button);
	   break;
      default: break;
   }
}

注釋

• 2007.01.13 編修（Revision）

Also See

2004.08.11: Nano-X 程式設計, #1：介紹與安裝 2004.04.26: Nano-X 程式設計, #2：「Hello World」 2007.01.13: Nano-X 程式設計, #3：顯示圖片（image.c）

]]> https://www.jollen.org/blog/2007/01/nano-x_programming_4.html https://www.jollen.org/blog/2007/01/nano-x_programming_4.html GNU Toolchains & Linux Systems Programming Sat, 13 Jan 2007 23:11:50 +0800 程式範例 image.c 是以 hello.c 為基礎，加上顯示圖片的功能。透過 image.c 我們可以學到以下的 Nano-X 程式設計方法：

˙ 如何使用嵌入式圖片
˙ 如何將圖片顯示於視窗上

由檔案讀取圖片檔並顯示顯示圖片是一般常見的做法，這裡我們所要實作的範例是希望可以將圖片直接嵌入程式裡，而不是由外部檔案讀取。

如何使用嵌入式圖片

要將圖片嵌入於程式裡，首先必須將圖片轉換成數值資料形式的 C 程式。Nano-X 提供一個檔名為 convbmp 的工具來將 BMP 格式的圖片轉換成 C 程式。

convbmp工具的原始程式位於 src/mwin/bmp/convbmp.c，這是提供給 Microwindows API 使用者的工具，因此我們在設定 Nano-X 編譯選項時，除了勾選 Nano-X API 外，還要勾選 Microwindows API 選項才能產生 convbmp 執行檔。編譯後可以在 src/bin/ 目錄下找到 convbmp，我們手動將此工具安裝到 /usr/bin/目錄下，以方便我們使用：

# cd microwin-0.89/
# cp src/bin/convbmp /usr/bin

先將取得的圖檔轉換成 BMP 的格式，再利用 convbmp 轉換成 C 程式。例如，我想轉換圖檔 jollen.bmp，那麼將圖檔轉換成 C 程式的指令就是：

$ convbmp jollen.bmp



圖（jollen.bmp）

轉換後便會得到 jollen.c。接著我們再修改 hello.c 將圖片顯示於視窗上。

如何將圖片顯示於視窗上

因為圖片資料屬於外部變數，因此先在程式裡宣告外部圖片變數：

extern GR_IMAGE_HDR image_jollen;

image_jollen 是一個陣列，存放圖檔的 pixel 資料，此陣列由 convbmp 轉換後產生，詳見 jollen.c 程式。接著，在處理 GR_EVENT_TYPE_EXPOSURE 事件的地方呼叫 GrDrawImageBits() 函數畫出圖片即可：

GrDrawImageBits(wid, gc, 0, 0, &image_jollen);

編譯時別忘了與 jollen.c 程式做連結，這個部份可以寫一個簡單的 Makefile rule來完成：

mage: image.o jollen.o
	$(CC) $(CFLAGS) $(LDFLAGS) $^ -o $@

以下是 image.c 的完整程式，粗體字是新加入的程式碼。

/*
 * Copyright(c) 2003,2004 www.jollen.org
 *
 * - Nano-X API example.
 * - image.c
 */

#include <stdio.h>
#define MWINCLUDECOLORS
#include <microwin/nano-X.h>

GR_WINDOW_ID wid;
GR_GC_ID gc;

/* 外部圖片 */
extern GR_IMAGE_HDR image_jollen;

void event_handler (GR_EVENT *event);

int main (void)
{
   if (GrOpen() < 0) {
        fprintf (stderr, "GrOpen failed");
        return -1;
   }

   gc = GrNewGC();
   GrSetGCForeground (gc, 0xFF0000);

   wid = GrNewWindowEx(GR_WM_PROPS_APPFRAME |
                       GR_WM_PROPS_CAPTION  |
                       GR_WM_PROPS_CLOSEBOX,
                       "jollen.org",
                       GR_ROOT_WINDOW_ID, 
                       0, 0, 
                       image_jollen.width, /* 圖片寬度 */ image_jollen.height /* 圖片高度 */, 
                       0xFFFFFF); GrSelectEvents(wid, GR_EVENT_MASK_CLOSE_REQ | GR_EVENT_MASK_EXPOSURE);

   GrMapWindow(wid);
   GrMainLoop(event_handler);

   return 0;
}

void event_handler (GR_EVENT *event)
{
   switch (event->type)
   {
      case GR_EVENT_TYPE_EXPOSURE:
           GrDrawImageBits(wid, gc, 0, 0, &image_jollen);
	   break;
      case GR_EVENT_TYPE_CLOSE_REQ: 
	   GrClose();
      default: break;
   }
}

注釋

• 2007.01.13 編修（Revision）

Also See

2004.08.11: Nano-X 程式設計, #1：介紹與安裝 2004.04.26: Nano-X 程式設計, #2：「Hello World」

]]> https://www.jollen.org/blog/2007/01/nano-x_programming_3.html https://www.jollen.org/blog/2007/01/nano-x_programming_3.html GNU Toolchains & Linux Systems Programming Sat, 13 Jan 2007 20:41:17 +0800 接續前一記日記的觀念：「Linux 以 sys_fork 或 sys_clone 來產生新的 process，而這二個 system call 最後都會呼叫到 do_fork() 函數，do_fork() 是 Linux 主要的 fork-routine。」

將此觀念以實作角度來說明的話，do_fork() 必須要做的工作便是「copy 原來的 process 成為另一個新的 process」。Linux 的 sys_fork() 內部實作就是以「copy process」的方式來實作。也就是說，當 user program 呼叫 fork() wrapper function 後，sys_fork() 便會「copy」原來的 process，以得到一個新的 process。

由此觀念的推導，我們便能了解到，sys_fork() 的內部實作關鍵便是：

1. 如何 copy process。

2. 要 copy process 的「哪個部份」？

這二個關鍵，都是相當值得玩味的題目，同時，透過探討「copy process」的核心實作，我們也可以強化「process address space」的觀念。以下先將 sys_fork() 的內部流程先大略 trace 一遍後，再討論「copy process」的主題；而「copy what」則會在「clone()」的專欄裡再做介紹。

首先，sys_fork() 與 sys_clone() 都呼叫到 do_fork routine。以下是 do_fork() 的原始碼：

/*
 *  Ok, this is the main fork-routine.
 *
 * It copies the process, and if successful kick-starts
 * it and waits for it to finish using the VM if required.
 */
long do_fork(unsigned long clone_flags,
	      unsigned long stack_start,
	      struct pt_regs *regs,
	      unsigned long stack_size,
	      int __user *parent_tidptr,
	      int __user *child_tidptr)
{
	struct task_struct *p; // 請見 1.
	int trace = 0;
	struct pid *pid = alloc_pid(); // 請見 2.
	long nr;

	if (!pid)
		return -EAGAIN;
	nr = pid->nr;
	if (unlikely(current->ptrace)) {
		trace = fork_traceflag (clone_flags);
		if (trace)
			clone_flags |= CLONE_PTRACE;
	}
	// 請見 3.
	p = copy_process(clone_flags, stack_start, regs, stack_size, parent_tidptr, child_tidptr, nr);
	/*
	 * Do this prior waking up the new thread - the thread pointer
	 * might get invalid after that point, if the thread exits quickly.
	 */
	if (!IS_ERR(p)) {
		struct completion vfork;

		if (clone_flags & CLONE_VFORK) {
			p->vfork_done = &vfork;
			init_completion(&vfork);
		}

		if ((p->ptrace & PT_PTRACED) || (clone_flags & CLONE_STOPPED)) {
			/*
			 * We'll start up with an immediate SIGSTOP.
			 */
			sigaddset(&p->pending.signal, SIGSTOP);
			set_tsk_thread_flag(p, TIF_SIGPENDING);
		}

		if (!(clone_flags & CLONE_STOPPED))
			wake_up_new_task(p, clone_flags);
		else
			p->state = TASK_STOPPED;

		if (unlikely (trace)) {
			current->ptrace_message = nr;
			ptrace_notify ((trace << 8) | SIGTRAP);
		}

		if (clone_flags & CLONE_VFORK) {
			wait_for_completion(&vfork);
			if (unlikely (current->ptrace & PT_TRACE_VFORK_DONE))
				ptrace_notify ((PTRACE_EVENT_VFORK_DONE << 8) | SIGTRAP);
		}
	} else {
		free_pid(pid);
		nr = PTR_ERR(p);
	}
	return nr;
}

我把重要的地方用紅色字體標示出來，一開始，我們必須先了解此部份的實作：

1. 宣告一個 process descriptor。

2. 要求一個 PID 給新的 process 使用。

3. 呼叫 copy_process()，以複制出新的 process。

由此可知，Linux kernel 的 copy_process() API 是重要的「process creation」API。

接著，把 copy_process() 的原始碼 trace 出來：

/*
 * This creates a new process as a copy of the old one,
 * but does not actually start it yet.
 *
 * It copies the registers, and all the appropriate
 * parts of the process environment (as per the clone
 * flags). The actual kick-off is left to the caller.
 */
static task_t *copy_process(unsigned long clone_flags,
				 unsigned long stack_start,
				 struct pt_regs *regs,
				 unsigned long stack_size,
				 int __user *parent_tidptr,
				 int __user *child_tidptr,
				 int pid)
{
...
}

copy_process() 程式碼有點多，這裡只先列出其函數原型。

看到 copy_process() 的第一個參數 clone_flags，這個參數一開始是由 sys_fork() 或是 sys_clone() 所傳遞進來的，並且 copy_process() 會根據 clone_flags 來決定「copy what」。

那麼我怎麼知道 clone_flags 有哪些值？這個部份定義在 <linux/sched.h> 標頭檔裡，以下是 clone_flags 的 bitwise 值定義：

/*
 * cloning flags:
 */
#define CSIGNAL		0x000000ff	/* signal mask to be sent at exit */
#define CLONE_VM		0x00000100	/* set if VM shared between processes */
#define CLONE_FS		0x00000200	/* set if fs info shared between processes */
#define CLONE_FILES	0x00000400	/* set if open files shared between processes */
#define CLONE_SIGHAND	0x00000800	/* set if signal handlers and blocked signals shared */
#define CLONE_PTRACE	0x00002000	/* set if we want to let tracing continue on the child too */
#define CLONE_VFORK	0x00004000	/* set if the parent wants the child to wake it up on mm_release */
#define CLONE_PARENT	0x00008000	/* set if we want to have the same parent as the cloner */
#define CLONE_THREAD	0x00010000	/* Same thread group? */
#define CLONE_NEWNS	0x00020000	/* New namespace group? */
#define CLONE_SYSVSEM	0x00040000	/* share system V SEM_UNDO semantics */
#define CLONE_SETTLS	0x00080000	/* create a new TLS for the child */
#define CLONE_PARENT_SETTID	0x00100000	/* set the TID in the parent */
#define CLONE_CHILD_CLEARTID	0x00200000	/* clear the TID in the child */
#define CLONE_DETACHED		0x00400000	/* Unused, ignored */
#define CLONE_UNTRACED		0x00800000	/* set if the tracing process can't force CLONE_PTRACE on this clone */
#define CLONE_CHILD_SETTID		0x01000000	/* set the TID in the child */
#define CLONE_STOPPED		0x02000000	/* Start in stopped state */

/*
 * List of flags we want to share for kernel threads,
 * if only because they are not used by them anyway.
 */
#define CLONE_KERNEL	(CLONE_FS | CLONE_FILES | CLONE_SIGHAND)

以 sys_fork() 的實作來看：

asmlinkage int sys_fork(struct pt_regs regs)
{
	return do_fork(SIGCHLD, regs.esp, ®s, 0);
}

呼叫 fork() wrapper function 時，並無法讓 user 自行定義 clone flags；因此，「在學會 clone() 函數的用法前」，其實可以先暫時跳過 clone flags 這個部份。

到這裡是 sys_fork() 內部實作的 trace，雖然我們了解到 clone flags 的作用，但是由於 sys_fork() 並不指定此參數，所以先不討論 clone flags。不過，我們的 sys_fork() trace 功課還沒完成，下一篇日記將會是「Process Creation, #5：copy process」。

以上 kernel trace，皆使用 Linux 2.6.17.7 原始程式碼。

Also See

2007.01.08: Process Creation, #3：sys_fork《基本觀念》 2007.01.02: Process Creation, #2：Running a "User Process" 2006.12.31: Process Creation, #1：由 shell 執行外部程式《基本觀念與範例》

]]> https://www.jollen.org/blog/2007/01/process_creation_4_sys_fork.html https://www.jollen.org/blog/2007/01/process_creation_4_sys_fork.html Linux Device Drivers & Kernel Thu, 11 Jan 2007 23:17:21 +0800 準提到「未初始化的全域變數（un-initialized global variables）其初始值為零（zero）」，所以得到的結果便是「程式執行時，必須將未初始化的全域變數都初始化成零」。 Linux 針對這種狀況的解決方式是「配置 zeroed pages 給 .bss section」，因此 un-initialized global variables 的值（value）便會為零。 註：Un-initialized global variables 會被編譯器放到 .bss section，可參考 Jollen 的「BSS Section 觀念教學」專欄。 此外，global variable 被初始化為零時，也會被 GCC 放到 .bss section 裡。所以，以下的寫法：

int foo; main() { ... }

會等於：

int foo = 0; main() { ... }

以上二種寫法都會讓 foo 被放到 .bss section。由此可知，以下二種狀況，變數都會被放在 .bss section： 1. 當 global variable 未被初始化時； 2. 或是 global variable 被初始化成零時。 -fno-zero-initialized-in-bss 如果（但是確實有這種應用場合）我們不想讓 variable 被放到 .bss section 呢？做法有二。第一種方式是「傳統做法」，程式設計師只要將 global variable 初始化為「非零」值即可，舉以下程式為例：

#include <stdio.h> int foo = 1; int main(void)
{
printf("foo is %d.\n", foo); return 0;
}

將此程式編譯：

$ gcc -O2 -o bss bss.c

利用 objdump 來觀察後，會發現 foo 變數被 GCC 放到 .data section 裡了。這種做法是基於 coding 時的做法。 第二種做法是 GCC 3.4.x 後所支援的「-fno-zero-initialized-in-bss」最佳化選項。將程式修改如下：

#include <stdio.h> int foo = 0; int main(void)
{
printf("foo is %d.\n", foo); return 0;
}

請特別留意，global variable 仍要做初始化，所以「foo」一定要做「assignment」為零值的動作。將程式編譯：

$ gcc -fno-zero-initialized-in-bss -O2 -o bss bss.c

GCC 會把 foo 放到 .data section。同樣可利用 objdump 來觀察。 良好的 Embedded Linux 程式寫作習慣 了解以上的觀念後，我要來說明一個重要的觀念。由於某些特定應用，或是 target 需要將變數放在 .data section 裡，因此若是 Embedded Linux 的應用，建議應對全域變數做初始化，例如：

int x;
int y;
int z;

int main(void)
{
...
}

應將這種傳統 C 的寫作習慣調整為：

int x = 0;
int y = 0;
int z = 0;

int main(void)
{
...
}

良好的習慣養成，未來將會得到許多好處。 這種寫法並非傳統 C 語言所講的「多此一舉」，應該以 Linux systems software 的角度來思考：這種寫法便能搭配 GCC 的「-fno-zero-initialized-in-bss」或是「-fzero-initialized-in-bss（預設）」選項，來決定 global variable 要放到 .bss section 或是 .data section。]]> https://www.jollen.org/blog/2007/01/no-zero-initialized-in-bss.html https://www.jollen.org/blog/2007/01/no-zero-initialized-in-bss.html GNU Toolchains & Linux Systems Programming Wed, 10 Jan 2007 22:44:21 +0800 一個防止程式被玩耍的小技倆」中，Jollen 提供了一個稱為「Truncate It」的小工具，我把他的原始碼放在此處「http://tw.jollen.org/elf-programming/truncate_it.tar.bz2」，有興趣的朋友可下載回家把玩。 用法請參考前一則日記的介紹，另外，「Truncate It」只是一個「呈現概念的原型」，並未良好的 coding，除了結果是輸出到 stdout 外，現階段也只能處理 IA32 的 ELF image。 Truncate It 的原理 Truncate It 的原理相當簡單，我只是把「Section Header Table」等資訊由 ELF image 中移除，因此「標準工具」便無法處理 ELF image；這是由於 GNU binutils 的工具都是以 linking view 來解讀 ELF image 之故，若要正常反組譯「truncated ELF image」，就要以 execution view 的角度來解讀執行檔。 此外，Section Header Table 在 execution view 時是 optional 的，可參考 Jollen 先前的日記「ELF（Executable and Linking Format）格式教學文件, #1: ELF 簡介」。 以下以一個操作流程來說明 Truncate It 的原理： 1. 如下圖（objdump）。 2. 把前半段的內容切出來，存成 hello.trunc。

# dd if=hello of=hello.trunc bs=1308 count=1
讀入了 1+0 個區段
輸出了 1+0 個區段
# chmod a+x hello.trunc

0x51c 等於十進位 1308。其中，.bss section 的長度為 4，但是 0x51c 並不需要再加上 4，原因請參考 Jollen 的「BSS Section Concepts: .bss section 的基本觀念介紹專欄」。 此外，.bss section 在一般情況下都會是「strip 後的最後一個 section」。.bss section 不佔實體檔案空間，會有 .bss section 的存在，主要的原因是「因為當初 C 語言標準所種下的因。」]]> https://www.jollen.org/blog/2007/01/truncate_it_tricky_source.html https://www.jollen.org/blog/2007/01/truncate_it_tricky_source.html GNU Toolchains & Linux Systems Programming Tue, 09 Jan 2007 23:41:47 +0800 Qt Centre（The Ultimate Qt Community）釋出一則消息：「Qt Centre Programming Contest 2007」。嘿，Qt Centre 也和幾個 partners（這裡面當然有 Trolltech）辦起 Qt4 的程式設計比賽了。 社群手法 先前曾提到的「Embedded Linux 2006 十大回顧！」都是很「具體」的事件，不過若大環境來看，絕對可以加上一條「開放源碼的社群經營手法在 2006 年展現氣勢。」大家可以思考 Linux mobile 的爆炸性成長過程，與其策略手法，甚致是 IBM 的幾個 case study，便能了解「社群手法」的重要性。 因為形成了這樣的 ecosystem，因此更能促進 open source 運動的發展，這絕對是好事一樁，。 回歸正題 2007 年的開放源碼世界，除了「Linux mobile」會持續躍進外，「community」的經營手法當然也會是本年度的重點戲。 每次看到一些消息，腦筋都不免會跳脫常軌，出現一些奇怪的聯想。還是回到主題來吧。Qt4 的比賽當然不會是一個「解題（problem solving）」的比賽，看一下他的「Guidelines on how to win the contest」，特別強調的是： 1. idea。關鍵你的 idea 要「大」。 2. completeness。成果要完整能動。 3. portability。在幾個主要的 Qt4 平臺都能執行。 4. design。程式碼本身的設計要良好。 5. documentation。良好的註解與文件。 6. code quality。良好的程式碼。 7. tests。必須透過一些解決方案來測試程式碼。 8. dependencies。基於 Qt 技術平臺。 9. team size。這個是說，團隊的人要多，一人隊伍是無法贏得比賽的。 我覺得這幾個 keywords 是很不錯的，可以比較一般化的把這幾個想法應用在 Embedded Linux 專案計畫中。例如：code quality 方面，「self-explainable variable names」是基本功；又如，在「dependencies」方面，因為是 Embedded Linux 開發，限制程式人員所能使用的 library 與 application 則是合理的。]]> https://www.jollen.org/blog/2007/01/qt_centre_programming_contest.html https://www.jollen.org/blog/2007/01/qt_centre_programming_contest.html 其它 Mon, 08 Jan 2007 23:32:52 +0800 fork() 是「Process Creation」議題的重要里程碑：提到 system call 代表著我們的研究要正式進入 kernel space 的層面了。

值得附帶一提的是，sys_fork 是一個 machine-dependent 的 system call，以 i386 為例，其實作位於 linux/arch/i386/kernel/process.c。^*1

Operating System 端的觀念

sys_fork 是非常重要的 system call，從作業系統的角度來解釋的話，這就是「建立 process」的主要 system call。當外部程式（即 ELF image）被使用者鍵入指令後，shell 便會呼叫 fork() 系統呼叫，並透過作業系統的 fork system call 來產生新的 process，以執行此外部程式。這種類型的 fork 也稱做 spawn。

可參考先前 Jollen 所分享的「Process Creation」前二則日記，以便了解 spawn、fork、exec 等等觀念：

• 2007.01.02: Process Creation, #2：Running a "User Process"
• 2006.12.31: Process Creation, #1：由 shell 執行外部程式《基本觀念與範例》

強烈建議您先閱讀以上二則日記，並了解 user-space 端的 process 觀念後，再繼續往下學習，才能更容易「感受」fork system call 的觀念。

Linux 端的觀念

Linux 並沒有 spawn system call，根據「Process Creation」日記的解說，Linux 下的 fork + exec 等於 spawn。而其中最核心的觀念則是在於 fork 的實作，也就是「如何產生新的 process」。

Linux 以 sys_fork 或 sys_clone 來產生新的 process，而這二個 system call 最後都會呼叫到 do_fork() 函數，do_fork() 是 Linux 主要的 fork-routine。繼續探討 do_fork() 時，便會接觸到以下二個重要議題： 

• memory descriptor（struct mm_struct）
• memory area（VMA）

關於更深入的 fork()，我們就先在此打住，下篇日記《核心實作》再做介紹。以下是 sys_fork() 與 sys_clone() 的程式碼（Linux 2.6.17.7::arch/i386/kernel/process.c）：

asmlinkage int sys_fork(struct pt_regs regs)
{
	return do_fork(SIGCHLD, regs.esp, ®s, 0, NULL, NULL);
}

asmlinkage int sys_clone(struct pt_regs regs)
{
	unsigned long clone_flags;
	unsigned long newsp;
	int __user *parent_tidptr, *child_tidptr;

	clone_flags = regs.ebx;
	newsp = regs.ecx;
	parent_tidptr = (int __user *)regs.edx;
	child_tidptr = (int __user *)regs.edi;
	if (!newsp)
		newsp = regs.esp;
	return do_fork(clone_flags, newsp, ®s, 0, parent_tidptr, child_tidptr);
}

do_fork() 的函數原型：

/*
 *  Ok, this is the main fork-routine.
 *
 * It copies the process, and if successful kick-starts
 * it and waits for it to finish using the VM if required.
 */
long do_fork(unsigned long clone_flags,
	      unsigned long stack_start,
	      struct pt_regs *regs,
	      unsigned long stack_size,
	      int __user *parent_tidptr,
	      int __user *child_tidptr);

clone_flags 是 do_fork() 觀念的核心，也是很有趣的議題。

Also See

*12006.10.11: Linux 2.6 的 System Call：12 大類

]]> https://www.jollen.org/blog/2007/01/process_creation_3_sys_fork.html https://www.jollen.org/blog/2007/01/process_creation_3_sys_fork.html Linux Device Drivers & Kernel Mon, 08 Jan 2007 13:44:14 +0800 由 user process 角度來說明的話，VMA 是 user process 裡一段 virtual address space 區塊；virtual address space 是連續的記憶體空間，當然 VMA 也會是連續的空間。VMA 對 Linux 的主要好處是，可以記憶體的使用更有效率，並且更容易管理 user process address space。

從另一個觀念來看，VMA 可以讓 Linux kernel 以 process 的角度來管理 virtual address space。Process 的 VMA 對映，可以由 /proc/<pid>/maps 檔案查詢；例如 pid 1（init）的 VMA mapping 為：

$ cat /proc/1/maps
08048000-0804e000 r-xp 00000000 08:01 12118      /sbin/init
0804e000-08050000 rw-p 00005000 08:01 12118      /sbin/init
08050000-08054000 rwxp 00000000 00:00 0
40000000-40016000 r-xp 00000000 08:01 52297      /lib/ld-2.2.4.so
40016000-40017000 rw-p 00015000 08:01 52297      /lib/ld-2.2.4.so
40024000-40025000 rw-p 00000000 00:00 0
40025000-40157000 r-xp 00000000 08:01 58241      /lib/i686/libc-2.2.4.so
40157000-4015c000 rw-p 00131000 08:01 58241      /lib/i686/libc-2.2.4.so
4015c000-40160000 rw-p 00000000 00:00 0
bfffe000-c0000000 rwxp fffff000 00:00 0　

列表中的欄位格式如下：

start-end perm offset major:minor inode image

Linux 以 struct vm_area_struct 資料結構來紀錄每一「區塊」的 VMA 資訊（include/linux/mm.h）：

struct vm_area_struct {
        struct mm_struct * vm_mm;
        unsigned long vm_start;
        unsigned long vm_end;

        struct vm_area_struct *vm_next;

        pgprot_t vm_page_prot;
        unsigned long vm_flags;

        rb_node_t vm_rb;

        struct vm_area_struct *vm_next_share;
        struct vm_area_struct **vm_pprev_share;

        struct vm_operations_struct * vm_ops;

        unsigned long vm_pgoff;

        struct file * vm_file;
        unsigned long vm_raend;
        void * vm_private_data;
};

struct vm_area_struct 裡有 3 個欄位，用來來維護 VMA 資料結構：

˙ unsigned long vm_start：記錄此 VMA 區塊的開始位址（start address）。
˙ unsigned long vm_end：記錄此 VMA 區塊的結束位址（end address）。
˙ struct vm_area_struct *vm_next：指向下一個 VMA 區塊結構的指標（Linux 以 linked list 資料結構維護每一個 VMA 區塊）。

VMA 的實作主要是為了能更有效率地管理記憶體，並且是基於 paging 系統之上所發展出的；VMA 是比原始 paging 理論更高階的記憶體管理方法。

]]> https://www.jollen.org/blog/2007/01/linux_virtual_memory_areas_vma.html https://www.jollen.org/blog/2007/01/linux_virtual_memory_areas_vma.html Linux Device Drivers & Kernel Fri, 05 Jan 2007 14:08:01 +0800 Busybox 於 2006-12-14 釋出 1.3.0（stable）版，並於 2006-12-27 釋出 1.3.1（stable）更新。不過，吸引我的並不是這個平凡的版本更新資訊，而是看到以下這段文字：

This release has CONFIG_DESKTOP option which enables features needed for busybox usage on desktop machine.

'CONFIG_DESKTOP' 的出現，讓原本是應用在 Embedded Linux 場合的 Busybox，也開始支援 Desktop Linux 的應用了。於是，我心裡浮現出以下的感想... Busybox 原先的設計理念是基於「簡化的系統工具」與「簡單化的指令集」，並朝 footprint 的目標而發展；當初由於 target device 硬體環境的貧乏（如 RAM 只有 4Mbytes），因此這種做法不但合情合理，並且也很「直覺」（make sense）。 現在，target device 硬體端技術的進步，讓 Embedded Linux 與 Desktop Linux 之間的界線越來越模糊。「根本上的定義」，Embedded Linux 是最小化的 Linux 系統，於是我們要學會 root filesystem 的建置，並儘最大力氣把它做到最小（down size）；如今，最小化，或是對尺寸的敏感性，在一些 Embedded Linux 的應用場合上，都不再是重點，甚致可以用「精簡大小不 make sense」來回應。 當 Embedded Linux 隱約等於 Desktop Linux 時，根本上的 Embedded Linux 技能（也就是建置最小化的 root filesystem）仍然是必備的基本能力，但是許多「Auto Build」的環境才是實用的做法；在這樣的前提下，所謂的 Embedded Linux 可能需要再重新定義。如果由「技術上的定義」來解釋，BSP 與週邊界面可能才能叫做「基本能力」，例如：如何 porting 某 SOC NAND flash controller 的 Linux 驅動程式，至於 root filesystem 的話，「就交給滑鼠左鍵吧」。 ]]> https://www.jollen.org/blog/2007/01/embedded_linux_busybox_desktop.html https://www.jollen.org/blog/2007/01/embedded_linux_busybox_desktop.html Embedded Linux: Platforms and Applications Fri, 05 Jan 2007 00:05:17 +0800 今天在分享自己實作上的經驗時，聊到「如何防止程式被人家玩了！」。我們所要實現的想法很簡單，就是設法防止「執行檔」被 Linux 下的「標準程式工具」給把玩了！例如：
• 防止被 "objdump" 工具讀取
• 防止被 "objdump –d" 做反組譯
• 防止被 gdb 除錯
• 防止 symbol table 被 nm 讀出
• 防止被其它的標準程式工具（GNU bintuils，如 file 等）所操作

我分享了一個簡單的方法，這個方法在以往「Linux Systems Programming」的課或多或少也曾向同學介紹過；不過，大家要知道的是，這只是一個有趣的小東西，或者說是一個「小手段」，任何高手級的 Linux 玩家，大概只要不到一小時就能輕易 反擊這個做法。

實測

就拿 "tar" 指令來看，以下是正常的操作：

# objdump -d /bin/tar

/bin/tar:     file format elf32-i386

Disassembly of section .init:

08049734 <.init>:
 8049734:       55                      push   %ebp
 8049735:       89 e5                   mov    %esp,%ebp
 8049737:       83 ec 08                sub    $0x8,%esp
 804973a:       e8 b1 07 00 00          call   0x8049ef0
 804973f:       e8 0c 08 00 00          call   0x8049f50
 8049744:       e8 93 b7 01 00          call   0x8064edc
 8049749:       c9                      leave
 804974a:       c3                      ret
Disassembly of section .plt:
...

把 "tar" 做「處理」後，這些標準的工具全都失效了。先用 Jollen 提供的小工具處理 /bin/tar：

# ./truncate_it /bin/tar > ./tar.trunc
# chmod a+x tar.trunc

再執行 objdump 試試：

# objdump -d tar.trunc
objdump: tar.trunc: File truncated

連 nm、gdb 等，也都失效了：

# nm tar.trunc
nm: tar.trunc: File truncated
[root@mail tmp]# gdb tar.trunc
GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"..."/tmp/tar.trunc": not in executable format: File truncated

(gdb) r
Starting program:
No executable file specified.
Use the "file" or "exec-file" command.

但是程式是可以正常使用的，不會有什麼問題：

# ./tar.trunc --help|more
GNU `tar' saves many files together into a single tape or disk archive, and
can restore individual files from the archive.

Usage: ./tar.trunc [OPTION]... [FILE]...

Examples:
  ./tar.trunc -cf archive.tar foo bar  # Create archive.tar from files foo a
nd bar.
  ./tar.trunc -tvf archive.tar         # List all files in archive.tar verbo
sely.
  ./tar.trunc -xf archive.tar          # Extract all files from archive.tar.

If a long option shows an argument as mandatory, then it is mandatory
for the equivalent short option also.  Similarly for optional arguments.
...

基本上，「執行時期都正常」，但是「程式的操作工具都失效」是這個小技巧能達成的效果。反過來想，既然 run-time 是正常的，那麼也就難逃 run-time 除錯工具的荼毒了。

下載程式

做法與原理是相當簡單的，只要知道「如何活用 ELF 規格」，箇中奧妙就不難懂了。大家可以下載 Jollen 寫的小程式「Truncate It」，這是一個執行檔，下篇日記我會介紹「Truncate It」的原理並提供 source code。使用方法如下：

# ./truncate_it /bin/tar > tar.trunc

記得 chmod 成可執行：

# chmod a+x tar.trunc

然後可以在「目前的目錄下」得到 tar.trunc 執行檔。

truncate_it 可以針對 ELF 的執行檔做一些小動作，並產生一個新的執行檔（結果輸出到 stdout）。被 truncate_it 處理過的檔案「大部份」都能正常執行，並且無法使用 GNU binutils 或是 gdb 對他做作何動作。

]]> https://www.jollen.org/blog/2007/01/truncate_it_tricky.html https://www.jollen.org/blog/2007/01/truncate_it_tricky.html Embedded Linux: Platforms and Applications Thu, 04 Jan 2007 01:51:10 +0800 Process Creation

在討論「Process Creation」議題時，首先要了解的就是「Linux 的三種 Process」。同樣是「執行中的程式（process）」，但是依其「特性（design perspective）」區分的話，可以歸納為以下三種：

• idle process

• kernel threads

• user process

其中「user process」就是我們此系列日記所要介紹的對象。User process 是很單純的一種 process，簡單來說，以下二種「執行程式的方式」就是 user process：

• 在 shell 模式中輸入 Linux command 所執行的外部程式

• 由 init process 所執行的外部程式

那麼 user process 是怎麼執行的呢？嗯，先前我們提過的日記「Process Creation, #1：由 shell 執行外部程式《基本觀念與範例》」便介紹了這樣的觀念。

Process Creation：Running a Program

接著，我們就以一張圖來展示「在 shell 模式執行外部程式（running a program）」的流程。



這樣就很清楚了：

1. 由 user 鍵入 UNIX command

2. shell 在 PATH 路徑中尋找 command，即外部程式（stored program）

3. shell fork/clone 自己，然後 child process 會將自己取代為 ELF image^*1

至於「idle process」與「kernel threads」則不適用此圖！

*1 即外部程式：Linux 的執行檔為 ELF 的格式，所以稱其為「ELF image」

Also See

2006.12.31: Process Creation, #1：由 shell 執行外部程式《基本觀念與範例》

]]> https://www.jollen.org/blog/2007/01/process_creation_2.html https://www.jollen.org/blog/2007/01/process_creation_2.html Linux Device Drivers & Kernel Tue, 02 Jan 2007 23:08:35 +0800 ]]> https://www.jollen.org/blog/2007/01/2007_new_year.html https://www.jollen.org/blog/2007/01/2007_new_year.html 其它 Mon, 01 Jan 2007 00:52:44 +0800 本系列專欄是「了解 ELF 動態時期行為」的前導專欄，建議您先行爬文「理解 dynamic loader 內部原理的幾個先備知識（下）：Kernel 端的議題」。
Shell 執行外部程式的觀念

在 2006 年的最後一天，就先來解說一下「下指令後、程式怎麼載入與執行」的觀念。首先，您必須知道並具備以下的 Linux 系統程式觀念：

1. fork() 系統呼叫：用來建立 child process。
2. exec 系列系統呼叫：以一個「外部程式」來取代自己（current process）的執行空間。
3. parent process、child process 與 Linux process tree。

了解以上三個主題後，就可以很容易理解「下指令後、程式怎麼載入與執行」的過程；這是很重要且基本的三個議題，若您不是很清楚這三個議題的觀念，可以查詢「Linux Systems Programming」的相關文件。

接下來，首先我們要知道的是，Linux 並沒有提供 "spawn" 的 system call；再來，shell 執行外部程式的做法是使用「spawn 版」的 fork() 實作。

好像又把大家搞胡塗了。所謂的「spawn 版的 fork()」，用對照的方式來說明會很清楚：

1. 真正的 spawn() 是「建立一個外部程式的 child process」；
2. 而 Linux 下討論的 fork() 則是「建立一個與父程序（parent process）完全相同的 process」。

也就是說，Linux 下的 fork() 是「non-spawn behavior」，因為他不會去跑一個外部程式，而是「複製 parent process 成為 child process」；那麼，要怎麼做出「spawn behavior」的 fork() 呢？方法很簡單：

1. 我們已經學過， exec 系列系統呼叫會以一個「外部程式」來取代 current process 的執行空間，所以不能在 parent process 裡叫用 exec system call 來跑外部程式；否則 parent process 會消失。
2. fork() 可以建立 child process，並且不讓 parent process 消失。
3. 所以，如果先 fork() 出 child process，再讓外部程式取代 child process，那麼就可以實作出「spawn style 的 fork()」了。

小結

Jollen 一開始就打算以邏輯思考（理論推演）的方式來介紹「觀念」，所以講了這麼多，希望不會造成您閱讀上的困擾。引用「書上寫的」應可以勝過以上的長篇大論：

Shell 執行外部程式的做法是先 fork 出自己的 child process，然後在 child process 裡使用 exec 系統呼叫外部程式，以執行外部程式。

很簡單的概念，只是記結論的話多少會少掉一些思考的樂趣。依此來看，邏輯上（Linux programming view）「可視 spawn 為 fork + exec」；實際上，若由 kernel view 來解讀，spawn 並不等於 fork + exec。

程式範例

看此範例需要知道 fork() 與 exec 系列函數的用法，您可參考「Linux Systems Programming」相關文件。

/*
 * Copyright(c) 2003,2004,2005,2006 www.jollen.org
 *
 * Spawn-style Linux fork().
 *
 * This file is GPLed.
 */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>

int spawn(char *prog, char **arg_list)
{
   pid_t child;

   child = fork();

   if (child != 0) {
      return child;
   } else {
      execvp(prog, arg_list);
      fprintf(stderr, "spawn error\n");
      return -1;
   }
}

int main()
{
   char *arg_list[] = {	
      "ls",  
      "-l",
      "/tmp",
      NULL };	

   spawn("ls", arg_list);

   return 0;
}

以上範例可由「http://tw.jollen.org/elf-programming/spawn_fork.c」下載。

Happy New Year ;-)

]]> https://www.jollen.org/blog/2006/12/process_creation_1_shell.html https://www.jollen.org/blog/2006/12/process_creation_1_shell.html Linux Device Drivers & Kernel Sun, 31 Dec 2006 20:14:16 +0800 理解 dynamic loader 內部原理的幾個先備知識（上）」時提及，必須略懂 .bss section 的觀念，並且最後也提到「之後再寫日記，以一段 code 來說明。」。其實之後幾天我就把介紹 .bss section 觀念的日記寫好了，只是還沒有加入到專欄索引，趕快來把索引做好！ 今天加入「BSS Section Concepts: .bss section 的基本觀念介紹」的專欄索引。 以下是必讀的二個專欄（及理由）： 1. 必須先懂 ELF 到底是什麼東西，才會知道 .bss 是 ELF 的「一個節區」。可以參考 Jollen 的「 Executable and Linking Format: 重要的 ELF 格式介紹」專欄。 2. 接著才是讀「BSS Section Concepts: .bss section 的基本觀念介紹」專欄。.bss section 是「動態時期（run time）」，而不是「靜態時期（stored）」的觀念，這真的是很重要。 除了「理解 dynamic loader 內部原理的幾個先備知識（上）」提到以 ELF 為主軸的幾個重要先備知識外，在開始研究 dynamic loader 前，還有幾個重要觀念也是要先懂的。其中與 kernel 相關的議題整理如下： 1. 就整體來看，最好了解 kernel 的開機流程，也就是由 bootloader 載入 kernel 後一直到 init process（user-space）的整個過程。這部份，Jollen 正在準備一篇簡單的文章來跟大家分享。 2. 就內部來看，必須知道「下指令後、程式怎麼載入與執行」的流程。大致來看，這涉及 shell、fork system call、exec system call 三大主題。這部份，Jollen 也打算寫篇日記來介紹。 了解以上二個重要觀念後，再切入研究 dynamic loader（例如：process 與 libc.so.6 如何 "dynamic" linking）時，腦細胞的連結才會比較順暢。]]> https://www.jollen.org/blog/2006/12/enabling_dynamic_loader_2.html https://www.jollen.org/blog/2006/12/enabling_dynamic_loader_2.html Linux Device Drivers & Kernel Fri, 29 Dec 2006 21:20:29 +0800 http://www.jollen.org/EmbeddedLinux/uClinux-dist.html」，需要時歡迎隨時上線取用。 ]]> https://www.jollen.org/blog/2006/12/update_uclinux-dist.html https://www.jollen.org/blog/2006/12/update_uclinux-dist.html 其它 Wed, 27 Dec 2006 14:17:08 +0800 Google Trends」可以用來幫助我們了解「關鍵字的搜尋趨勢」，結果丁小弟寄了以下二張圖片給我。 好一個「罄竹難書」。 ]]> https://www.jollen.org/blog/2006/12/google_trends.html https://www.jollen.org/blog/2006/12/google_trends.html 其它 Wed, 27 Dec 2006 01:51:56 +0800 重要觀念

任何作業系統底下的「驅動程式」，都需要分二個層面來討論所謂的「I/O 處理」：

1. 實體層：驅動程式 v.s. 硬體。

2. 虛擬層：驅動程式 v.s. user process

在前一篇日記「Linux 驅動程式的 I/O, #2: I/O 存取相關函數」中所提到的 I/O 函數是處理「實體層」的 I/O；本日記所要介紹的 copy_to_user() 與 copy_from_user() 則是在處理「虛擬層」的 I/O。另外，在繼續往下讀之前，您必須了解以下的觀念都是「等價」的：

1. 驅動程式與 user process 的 I/O；等於

2. 驅動程式與 user process 間的 data communication；等於

3. kernel-space 與 user-space 間的 data communication。

此外，還要了解：

1. user-space 無法「直接」存取 kernel-space 的記憶體。

2. 「Linux device driver」與「user-space」間的 I/O 會與 fops->read、fops->write 與 fops->ioctl 共三個 system call 有關。

copy_to_user() 與 copy_from_user()

了解以上的觀念後，再來「直接殺進重點」就很容易懂了：從 user-space 讀取資料至 kernel-space，或是將 kernel-space 的資料寫至 user-space，「必須」透過 kernel 提供的 2 個 API 來進行。這二個 API 如下：

˙ long copy_to_user(void *to, const void *from, long n);
˙ long copy_from_user(void *to, const void *from, long n);

參數說明，以 copy_to_user() 來說：

˙ to：資料的目的位址，此參數為一個指向 user-space 記憶體的指標。
˙ from：資料的來源位址，此參數為一個指向 kernel-space 記憶體的指標。
˙ 口訣：copy data to user-space from kernel-space

以 copy_from_user() 來說：

˙ to：資料的目的位址，此參數為一個指向 kernel-space 記憶體的指標。
˙ from：資料的來源位址，此參數為一個指向 user-space 記憶體的指標。
˙ 口訣：copy data from user-space to kernel-space

由 user-space 讀取資料，或是寫入資料給 user-space 的 3 個 driver method 為：read、write與ioctl。

另外，指向 user-space 的指標是 kernel 回呼 driver method 時所傳遞進來的，可由 read、write 與 ioctl driver function 的函數原型宣告來觀察（紅色部份）：

˙ int card_ioctl(struct inode *inode, struct file *filp, unsigned int cmd, unsigned long arg);
˙ ssize_t write(struct file *filp, const char *buff, size_t count, loff_t *offp);
˙ ssize_t read(struct file *filp, char *buff, size_t count, loff_t *offp);

fops->ioctl 的參數 arg、fops->write 與 fops->read 的參數 buff 是指向 user-space 資料的指標。撰寫程式時，要注意資料型別上的不同。

下一篇日記再寫一個範例來配合著研究，大家應該會更清楚。

Also See

2006.12.22: Linux 驅動程式的 I/O, #1: 基本概念 2006.12.20: Linux 驅動程式的 I/O, #2: I/O 存取相關函數

]]> https://www.jollen.org/blog/2006/12/linux_device_driver_io_3.html https://www.jollen.org/blog/2006/12/linux_device_driver_io_3.html Linux Device Drivers & Kernel Tue, 26 Dec 2006 23:40:04 +0800 Embedded Linux 2006 十大回顧」！內容提到今年 10 個主要的 embedded Linux 發展趨勢（以下是簡要翻譯，請閱讀原文有很完整的說明）： 1. Linux 也有自己的手機囉！ 2. 許多廠商開始提供完整（"complete"）的 mobile phone software stacks 了，參賽者有 Trolltech, a la Mobile, Cellunite, Aplix, Access！（Jollen 編註：事實上 2006 年出現在地球上的 mobile phone software stack（application framework）不只於此） 3. 關鍵性的 embedded Linux 開發工具！（Jollen 編註：最令人印像深刻的是 TimeSys 的「現成 RFS 服務」」） 4. AMD & Intel 賣掉他們「non-x86」的 mobile phone 處理器產品線！（Jollen 編註：你們這哥倆好要繼續努力喔！） 5. 真的不是蓋的，越來越多 Eclipse-based 的 embedded Linux 開發工具了！（Jollen 編註：其中以「MontaVista 推出 Dev Rock 5」是最重大的變革） 6. GPLv3 大激戰！ 7. 除了手機外，還有更多的 design wins！ 8. VoIP、TV 與 Set-top-box 的產品！ 9. Linux kernel 有了重大的 real-time enhancements！ 10. 許多 Linux 新規格的釋出！ 今年隨時保持 embedded Linux 發展動態的朋友，對這幾條新聞的出線絕對是不感到意外的。不容易被外力改變的方向叫做「趨勢」，希望未來的一年 embedded Linux 繼續加油！]]> https://www.jollen.org/blog/2006/12/embedded_linux_2006.html https://www.jollen.org/blog/2006/12/embedded_linux_2006.html Embedded Linux: Platforms and Applications Mon, 25 Dec 2006 21:05:32 +0800 Framework aims to commercialize mobile Linux apps」。 如果我的國文造詣還可以的話，以「雨後春筍」來形容「Linux application framework for mobile devices」應該是挺合適的；今年（２００６）如果要寫 Linux 年度大事記的話，這個主題絕對是前 10 名的。 本週是２００６年最後一週，也是為２００７年做準備的最後一週，輕鬆一下也是不錯的。 回歸正題 另一個以 GTK+ 為基礎的 Linux mobile devices 的「application framework」也釋出了，這個 application framework 叫做「Hiker Application Framework」，他是以 GTK+ 做為發展基礎的 Linux mobile devices 應用框架。 不久前曾經提到過的「OpenMoko」也是以 GTK+ 為基礎的 Linux mobile devices 應用框架（application framework）；OpenMoko 與 Hiker Application Framework 在授權上採取不同的策略。OpenMoko 以 GPL（but not as usual mentioned by OpenMoko's web site），Hiker Application Framework 則是以 MPL（Mozilla Public License）的授權釋出。 Hiker Application Framework 的資訊可參閱他的官方網站「Access」，並且可在此下載。 Hiker 於 2006 年 10 月份曾經發出過一份消息，可按此瀏覽。另外，Access 預計在 2007 年上半年釋出 SDK（software development kit）與 PDK（product development kit），值得一提的是，SDK 所提供的 GUI 工具是「Eclipse-based 」。]]> https://www.jollen.org/blog/2006/12/hiker_application_framework_linux_mobile.html https://www.jollen.org/blog/2006/12/hiker_application_framework_linux_mobile.html Embedded Linux: Platforms and Applications Mon, 25 Dec 2006 20:28:34 +0800

Merry Christmas and Happy New Year 2007! 　 　 祝 jollen.org 的所有朋友耶誕佳節愉快。 --jollen

]]> https://www.jollen.org/blog/2006/12/chirstmas_2007_merry.html https://www.jollen.org/blog/2006/12/chirstmas_2007_merry.html 其它 Fri, 22 Dec 2006 23:57:33 +0800 SEJeff」在 OSNews.com 上寫了一篇 Blog，內容提到「non-GPL Linux kernel modules will not work after January 2008」，結果更可怕的是截至目前（本日記出版時）為止，已經有 27x 篇的「comments」在討論這個話題。 Comments 裡頭各式各樣的延伸看法都有，大家可以去瞧瞧。]]> https://www.jollen.org/blog/2006/12/non-gpl_linux_kernel_module.html https://www.jollen.org/blog/2006/12/non-gpl_linux_kernel_module.html 其它 Thu, 21 Dec 2006 23:47:24 +0800 SDIO 是走 SD 插糟的週邊介面，SDIO 也是普及於 PDA/Mobile 的週邊規格，實際應用例如：透過 SDIO（SD 插糟），可以外接許多 SDIO 的週邊卡，像是 SDIO WiFi card 或是 SDIO CMOS sensor。Linux 從 2.6.17 開始正式加入了 SD/MMC 的 stack driver（也就是 API core 層），但是並沒有 SDIO 的 stack driver。

因此，「玩家」可以試著由現有的 SD/MMC stack 做修改，並實作 machine-dependent 的驅動程式（例如：s3c24x0）。或是花錢買解決方案，例如：MontaVista、印度的 embWise 公司。

Linux-SDIO Project

不過，有好消息。今天在 LinuxDevices.com 上看到一則新聞：MontaVista, Atheros contribute open-source SDIO stack。MontaVista 與 Atheros 攜手貢獻 open-source 的 SDIO stack，並且未來也會加到主流（mainline）的 Linux kernel（註：即 Linus 維護的 kernel）。這個動作解決目前幾個 SD/MMC 應用的問題：

1. Linux SDIO stack（Core API layer）終於有了完整的 open-source 版本。（但是不知道實際採用的意願高不高，不過對這個部份有興趣的玩家，終於不用再面對一疊厚厚的 spec. 發呆了。）

2. Linux 未來將能支援更多的 SDIO 週邊。目前除了 SD memory card、SDIO WiFi card 與 SDIO CMOS sensor 可以跑之外，不知道還有什麼 SDIO 週邊可以上到 Linux 的。

由於 Atheros 有 Linux 2.6 的 SDIO WiFi card patch，所以除了 Atheros 的卡可以上之外，好像也沒辦法在「網路上」找到別家的。

這裡有 [MontaVista 所維護的 Atheros WiFI card SDIO 驅動程式]。

3. MontaVista 與 Atheros 合作的這個 open-source 專案，做了一件很重要的事（引述報導原文）：

The linux-SDIO project will apparently endeavor to merge the Codetelligence/Atheros stack with the mainline kernel's existing linux-mmc subsystem.

此外（引述報導原文）：

our long term goal is to follow the community and just submit SDIO drivers to Pierre [Ossman, Linux's MMC subsystem maintainer], instead of duplicating the SDIO framework of host controller drivers and bus drivers.

所以 Linux-SDIO project 將會整合現有的 Linux-MMC subsystem（即 Stack 層、API）。表示未來 Linux 的 SD/MMC subsystem 只會有一套，而不是像現在的情況。例如：有些 MMC host controller 的 vendor 除了實作自己的 machine-dependent driver 外，也寫自己的 stack 層（只是沒有那麼完整、通用）。

4. Open-source 的價值之一是「製造出」各種完善的商業性支援（commerical support），所以許多工作並不需要自己來，或是自己做不來的工作也能輕鬆取得支援。以 SDIO stack 解決方案來說，未來將會有更多 IDH（Independent Design House）提供 SDIO 的協助，商業性的支援不會再是有錢人的專利了。

目前 Linux 2.6 現有的 SD/MMC stack 架構與程式碼實作，難度並不是很高，相當好理解，大家可以花點時間來研究這個部份，會很有幫助的。

Open-source SDIO stack，這真是個不錯的消息！

]]> https://www.jollen.org/blog/2006/12/linux_sdio_stack_open_source.html https://www.jollen.org/blog/2006/12/linux_sdio_stack_open_source.html Linux Device Drivers & Kernel Thu, 21 Dec 2006 17:09:23 +0800 I/O 存取相關函數 要提到「I/O 處理」當然要整理 Linux 提供的相關函數，以下分 3 大類來整理： 1. I/O port 2. I/O memory 3. PCI configuration space 4. ioremap I/O Port 以下是 Linux 提供最原始的 I/O port 存取函數： ˙ unsigned inb(unsigned port); ˙ unsigned inw(unsigned port); ˙ unsigned inl(unsigned port); ˙ void outb(unsigned char byte, unsigned port); ˙ void outw(unsigned short word, unsigned port); ˙ void outl(unsigned long word, unsigned port); I/O Memory 以下是 Linux 提供最原始的 I/O memory 存取函數： ˙ unsigned readb(unsigned port); ˙ unsigned readw(unsigned port); ˙ unsigned readl(unsigned port); ˙ void writeb(unsigned char byte, unsigned port); ˙ void writew(unsigned short word, unsigned port); ˙ void writel(unsigned long word, unsigned port); 對於 I/O memory 的操作，Linux 也提供 memory copy 系列函數如下： ˙ memset_io(address, value, count); ˙ memcpy_fromio(dest, source, num); ˙ memcpy_toio(dest, source, num); 以上在「Linux 驅動程式觀念解析, #6: 依流程來實作 -- Physical Device Driver」介紹過一次，並且也搭配了一個簡單範例做說明，您可參考該文。 PCI Configuration Space Linux 也提供讀寫 PCI configuration space（PCI BIOS）的函數： ˙ int pci_read_config_byte(struct pci_dev *dev, int where, u8 *val); ˙ int pci_read_config_word(struct pci_dev *dev, int where, u16 *val); ˙ int pci_read_config_dword(struct pci_dev *dev, int where, u32 *val); ˙ int pci_write_config_byte(struct pci_dev *dev, int where, u8 val); ˙ int pci_write_config_word(struct pci_dev *dev, int where, u16 val); ˙ int pci_write_config_dword(struct pci_dev *dev, int where, u32 val); 有些朋友可能看過開頭是 pcibios_* 的函數版本，「不過這是舊的函數，請勿再使用」。 ioremap() 這個 API 就重要到不行了，任何時候，Linux device driver 都「不能直接存取 physical address」。所以，「使用以上的 I/O 相關函數時，只能傳 virtual address，不能傳入 physical address」，ioremap() 就是用來將 physical address 對應到 virtual address 的 API。 小結 對於 I/O 函數的使用，應該在「深諳」Linux驅動程式架構與Linux作業系統原理的情況下使用，「單純的 kernel module + IO APIs」並不叫做 Linux 驅動程式，再更進一步的「kernel module + read/write/ioctl + IO APIs」也只是小聰明（編註），還是稱不上 Linux「驅動程式」。建構在作業系統裡的驅動程式，90% 都是在實作良好的機制與行為，因此「OS 原理與機制的研究」，才是正確的思考方向。與大家分享自己的心得，希望對您的學習有幫助。 編註：這是 Linux device driver 的「開始」但不是全部，也只是冰山一角。但是許多教育訓練機構的課程卻是以此為做為規劃方向，並不是很妥當。

Also See

2006.12.22: Linux 驅動程式的 I/O, #1: 基本概念

]]> https://www.jollen.org/blog/2006/12/linux_device_driver_io2.html https://www.jollen.org/blog/2006/12/linux_device_driver_io2.html Linux Device Drivers & Kernel Wed, 20 Dec 2006 22:57:48 +0800 為了能看到 2.11BSD on PDP-11 跑起來的樣子，所以要找一個簡單的方法先讓東西跑起來。由 tuhs 上 mirror 回來的一堆東西裡，找到 PDP-11/Boot_Images/2.11_on_Simh/211bsd.tar.gz 這個檔案，直接取用這個檔案，把它解開後發現裡頭有這麼多東西：



這裡頭的檔案是給 SIMH 模擬器用的，也就是「Bob Supnik's PDP simulator」。我用的是 SIMH V3.6-1，以下是編譯後得到的一堆古董機模擬器：



我把 211bsd.tar.gz 解在這個目錄下。接著用 PDP-11 的模擬器來開機：

$ ../pdp11 ./211bsd.simh

結果跑出這個畫面：



一時之間不曉得發生什麼事，結果按了個 [Enter] 後：



接下來，大家應該會做跟我一樣的動作：



還蠻酷的。

]]> https://www.jollen.org/blog/2006/12/simh_pdp-11_211bsd.html https://www.jollen.org/blog/2006/12/simh_pdp-11_211bsd.html 其它 Wed, 20 Dec 2006 18:16:21 +0800 The Unix Heritage Society 「The Unix Heritage Society（tuhs）」保留了很久以前的 UNIX 系統，引述 tuhs 網站上的一句話：

The preservation and maintenance of historical and non-mainstream UNIX systems.

tuhs 也提供 rsync 服務，所以我就把上面的檔案都抓回來了！根據 tuhs 網站上的說明，我下的 rsync 命令如下：

rsync -avz minnie.tuhs.org::UA_Root .
rsync -avz minnie.tuhs.org::UA_Applications Applications
rsync -avz minnie.tuhs.org::UA_4BSD 4BSD
rsync -avz minnie.tuhs.org::UA_PDP11 PDP-11
rsync -avz minnie.tuhs.org::UA_PDP11_Trees PDP-11
rsync -avz minnie.tuhs.org::UA_VAX VAX
rsync -avz minnie.tuhs.org::UA_Other Other

抓了好久，因為檔案差不多有 1.1 GB 左右。抓回這些東西：

jollen@jollen-work:~/tuhs$ ls
4BSD/                checksums.gz    lists/     Other/   rsync.sh  VAX/
Applications/        COPYRIGHTS      misc/      PDP-11/  tools/
Caldera-license.pdf  Documentation/  nohup.out  README   updates

又找了 DEC PDP-11 的模擬器，想來玩玩看這些古老級的 Unix。 The DEC Emulation Website 在這裡可以找到 DEC 的模擬器：http://www.aracnet.com/~healyzh/decemu.html，DEC PDP-11 的模擬器：http://www.aracnet.com/~healyzh/pdp11emu.html。不過還沒有實際裝起來玩過，只是覺得蠻酷的。 Bob Supnik's PDP simulator 從 tuhs 抓回來的東西裡找到可以在 Bob Supnik's simulator 上跑的 211BSD：

jollen@jollen-work:~/tuhs$ ls PDP-11/Boot_Images/2.11_on_rl02/
211bsd.boot.gz  211bsd.vol3.gz  211bsd.vol6.gz  211bsd.vol9.gz  README
211bsd.vol1.gz  211bsd.vol4.gz  211bsd.vol7.gz  patches         script
211bsd.vol2.gz  211bsd.vol5.gz  211bsd.vol8.gz  pdpsim.tz

Bob Supnik's PDP simulator 首頁：http://simh.trailing-edge.com/，裡頭有好多古董機的模擬器，PDP-11 模擬器的功能列表：http://simh.trailing-edge.com/pdp11.html。]]> https://www.jollen.org/blog/2006/12/the_unix_heritage_society_unix.html https://www.jollen.org/blog/2006/12/the_unix_heritage_society_unix.html 其它 Wed, 20 Dec 2006 16:07:40 +0800 步驟 1. 利用 gennanox 來產生主要的目錄（骨幹）： # sh ./gennanox generating fstab generating group generating passwd generating inittab generating rc.d/rc.init generating rc.d/rc.sysinit generating /bin/microwin 2. 得到 nanox/ 目錄： # ls -l nanox/ 總計 8 drwxr-xr-x 4 root root 4096 12月 19 18:55 i386.so drwxr-xr-x 2 root root 4096 12月 19 18:55 src # ls -l nanox/i386.so/ 總計 8 drwxr-xr-x 12 root root 4096 12月 19 18:55 install drwxr-xr-x 2 root root 4096 12月 19 18:55 pub nanox/install/ 存放我們的 root filesystem。 3. 把 package source tarball 都放到 nanox/src/，build 好的 binary 放到 nanox/i386.so/install/。 4. root filesystem 的 dev/ 不用再手動建立檔案。有一種更方便的方法是寫一個 device txt 檔，透過 genext2fs 來做，把下面的內容存成 dev.txt：

# name    type mode uid gid major minor start inc count
/dev      d    755  0    0    -    -    -    -    -
/dev/console c 666  0    0    5    1    0    0    -
/dev/fb   c    666  0    0   29    0    0    1    1
/dev/mouse c   666  0    0   10    1    0    0    -
/dev/ram  b    666  0    0    1    0    0    1    4
/dev/tty  c    666  0    0    5    0    0    0    -
/dev/tty  c    666  0    0    4    0    0    1    2
/dev/gpmdata p 666  0    0    -    -    -    -    -
/dev/null c    666  0    0    1    3    0    0    -
/dev/zero c    666  0    0    1    5    0    0    -
/dev/hda  b    666  0    0    3    0    0    0    -
/dev/hda  b    666  0    0    3    1    1    1    9
/dev/hdc  b    666  0    0   22    0    0    0    -
/dev/hdc  b    666  0    0   22    1    1    1    9

# usb mouse
#/dev/input/mice c 666 0  0   13   63    0    0    -
#/dev/mouse  c 666 0  0   13   63    0    0    -
/dev/input  d 755  0    0    -    -    -    -    -
/dev/input/mouse c 666 0  0   13   32    0    1    2
/dev/input/event c 666 0  0   13   64    0    1    4

5. 打包 RFS 時，透過 genext2fs 的 '-D' 參數來建立 device file。指令如下：

# cd nanox/i386.so/
# genext2fs -D dev2.txt -d install/ -b 2048 pub/ext2fs
# gzip -9 pub/ext2fs
#

把 RFS（install/）打包成 image file 時，genext2fs 會根據 dev.txt 的設定來建立 device file。打包好的 image file 要放到 nanox/i386.so/pub/ 目錄下，以便能系統性的管理整個 project。 以上的 dev.txt 同樣由 Joe 老師提供，他也把 USB mouse 的 device file 設定好了。gennanox 可以說是「用來產生 nano-X project 基本骨架（framework）」的 script。 Thanks Joe!]]> https://www.jollen.org/blog/2006/12/genext2fs_device_file_table.html https://www.jollen.org/blog/2006/12/genext2fs_device_file_table.html Embedded Linux: Platforms and Applications Tue, 19 Dec 2006 18:50:46 +0800 # cd /home/rootfs
# find . | cpio -o -H newc | gzip -9 >../cramfs.gz 更明確地說，initramfs 是 "compressed" ramfs（ram filesystem），ramfs 並不等於傳統的 ramdisk；像是以 "genext2fs" 工具所製作的 initrd（ext2 格式的 image file）才是基於 ramdisk 的傳統做法，也就是說，initramfs 並不等於傳統上的 initrd，這點要請大家多留意。 ]]> https://www.jollen.org/blog/2006/12/root_filesystem_initramfs.html https://www.jollen.org/blog/2006/12/root_filesystem_initramfs.html Embedded Linux: Platforms and Applications Tue, 19 Dec 2006 01:10:53 +0800 目前已經了解到：.bss section 在 linking view 時是不佔檔案長度的，在 execution view 時，根據其長度來佔用記憶體大小。

關於 .bss section 的結構，其實一張圖就夠了。直接切入重點吧！

前言

先重新編譯 bss.c 範例：

# gcc -g -o bss bss.c
# ./bss
.bss section starts at 0x8049588
foo is 0.
foo is 12345.
.bss section starts at 0x8049588

依照先前日記的說明，.bss section 的長度為 12 bytes。無論程式是否有 uninitialized data，process 一定會有 .bss section，並且 .bss section 的長度至少為 4 bytes（IA32），第一筆資料是 "completed.1"，該筆資料紀錄 .bss section 的起啟位址。

另外，在「linker script」裡，定義了一個叫 "__bss_start" 的符號，此符號才是紀錄 .bss section 的真正起始位址。不過，在此先不討論這個部份。

Process 的 .bss section 結構

Process 的 .bss section 佔用的記憶體大小，是根據 .bss section 的長度，在執行時期為每一筆 uninitialized data 保留下來的。其結構如下圖所示，我們以 bss.c 的範例來說明。



圖 .bss section 結構

由圖可以知道，範例的 .bss section 其 start address 為 0x8049584，這是直接查詢 .bss section 裡的 "completed.1" 符號得知的。'completed.1' 的 address 可利用 nm 查詢：

# nm -v bss|grep 'completed.1'
08049584 b completed.1

由此了解，.bss section 真正的 start address 應該是 'completed.1'；不過，若把第一筆資料的 start address 當做 .bss section 的 start address 其實也無妨，或者說這是 .bss section「放 data」的 start address。

利用 gdb 來觀察

# gdb ./bss
...
(gdb) disassemble 0x8049588
Dump of assembler code for function foo:
0x08049588 <foo+0>: add %al,(%eax)
0x0804958a <foo+2>: add %al,(%eax)
End of assembler dump.
(gdb) disassemble 0x8049584
Dump of assembler code for function completed.1:
0x08049584 <completed.1+0>: add %al,(%eax)
0x08049586 <completed.1+2>: add %al,(%eax)
(gdb) disassemble 0x804958c
Dump of assembler code for function bar:
0x0804958c <bar+0>: add %al,(%eax)
0x0804958e <bar+2>: add %al,(%eax)
End of assembler dump.

Also See

2006.12.15: .bss section 的觀念：uninitialized data section 2006.12.15: .bss section 的觀念：執行時期的長度

]]> https://www.jollen.org/blog/2006/12/bss_section_3.html https://www.jollen.org/blog/2006/12/bss_section_3.html Linux Device Drivers & Kernel Sun, 17 Dec 2006 22:02:26 +0800 理解 dynamic loader 內部原理的幾個先備知識（一）」講到：.bss 節區「linking view」上不佔檔案空間。這點可以用 readelf 來做 ELF linking view 端的印證：

# readelf -e bss|more  (bss 是我們的範例執行檔)
...
Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .interp           PROGBITS        080480f4 0000f4 000013 00   A  0   0  1
  [ 2] .note.ABI-tag     NOTE            08048108 000108 000020 00   A  0   0  4
  [ 3] .hash             HASH            08048128 000128 000028 04   A  4   0  4
  [ 4] .dynsym           DYNSYM          08048150 000150 000050 10   A  5   1  4
  [ 5] .dynstr           STRTAB          080481a0 0001a0 00004c 00   A  0   0  1
  [ 6] .gnu.version      VERSYM          080481ec 0001ec 00000a 02   A  4   0  2
  [ 7] .gnu.version_r    VERNEED         080481f8 0001f8 000020 00   A  5   1  4
  [ 8] .rel.dyn          REL             08048218 000218 000008 08   A  4   0  4
  [ 9] .rel.plt          REL             08048220 000220 000010 08   A  4   b  4
  [10] .init             PROGBITS        08048230 000230 000017 00  AX  0   0  4
  [11] .plt              PROGBITS        08048248 000248 000030 04  AX  0   0  4
  [12] .text             PROGBITS        08048278 000278 0001b8 00  AX  0   0  4
  [13] .fini             PROGBITS        08048430 000430 00001b 00  AX  0   0  4
  [14] .rodata           PROGBITS        0804844c 00044c 000031 00   A  0   0  4
  [15] .eh_frame         PROGBITS        08048480 000480 000004 00   A  0   0  4
  [16] .data             PROGBITS        08049484 000484 00000c 00  WA  0   0  4
  [17] .dynamic          DYNAMIC         08049490 000490 0000c8 08  WA  5   0  4
  [18] .ctors            PROGBITS        08049558 000558 000008 00  WA  0   0  4
  [19] .dtors            PROGBITS        08049560 000560 000008 00  WA  0   0  4
  [20] .jcr              PROGBITS        08049568 000568 000004 00  WA  0   0  4
  [21] .got              PROGBITS        0804956c 00056c 000018 04  WA  0   0  4
  [22] .bss              NOBITS          08049584 000584 00000c 00  WA  0   0  4
  [23] .comment          PROGBITS        00000000 000584 000132 00      0   0  1
...

重點的部份我用粗體字標示出來了：.bss section 與 .comment section 在檔案裡的 offset 是相同的。不過，用「他人」的工具來印可能會有一些盲點存在，比如說，我們可能不是很明白「Off」真正的意義；建議使用我們自行撰寫的 ELF 讀檔程式 loader-0.5.c（下載）來做，因為這是自己寫的工具，能保證一些盲點都能得到證明。以下是用 loader-0.5.c 印出來的畫面：

# ./loader bss
ELF Identification
  Class:        32-bit objects
Machine:        Intel 80386
Name                Size FileOff
[00] .interp               19     244
[01] .note.ABI-tag         32     264
[02] .hash                 40     296
[03] .dynsym               80     336
[04] .dynstr               76     416
[05] .gnu.version          10     492
[06] .gnu.version_r        32     504
[07] .rel.dyn               8     536
[08] .rel.plt              16     544
[09] .init                 23     560
[10] .plt                  48     584
[11] .text                440     632
[12] .fini                 27    1072
[13] .rodata               49    1100
[14] .eh_frame              4    1152
[15] .data                 12    1156
[16] .dynamic             200    1168
[17] .ctors                 8    1368
[18] .dtors                 8    1376
[19] .jcr                   4    1384
[20] .got                  24    1388
[21] .bss                  12    1412
[22] .comment             306    1412

了解 ELF 並自己撰寫工具，此過程讓我們了解到「Offset」指的是「確實是該 section 在檔案裡的啟始讀取位置」。這代表，無論程式裡有多少 uninitialized data，都是不佔用額外的檔案空間的。 畫面中的節區大小 「Size」代表該 section 的實體大小（in bytes），以 .bss section 來說，.bss section 的大小是 12 bytes。很不幸的是，這個大小並非表示 .bss section 佔用的「檔案大小」，而是「記憶體大小」；這可能會是一個使用工具時，因為畫面的「字義」所不小心產生的盲點。所以如果把 .bss section 的 Offset 加上他的 Size，並不會等於 .comment section 的 Offset。 所謂的「Size」，包含由 objdump 與 readelf 所列印出來的畫面，或者說，「紀載在 section header entry」裡的 size 資訊，是表示「該 section 的實體記憶體大小」。 .bss section 的長度計算方式 .bss 的大小計算方式為（IA32 平臺）：

4 bytes + sizeof(所有的 uninitialized data)

這代表 .bss section 在記憶體所會佔用的長度。以先前的例子來說，計算式會是：

4 + sizeof(foo) + sizeof(bar) = 4 + 4 + 4 = 12 (bytes)

所以，.bss section 的「size」field 就是 12。 .bss section 的結構 .bss section 的空間結構類似於 stack，所以前一則日記講述的「foo 是第一個 uninitialized data，所以他的 virtual address，形同 .bss section 的開始位址（process virtual address）。」觀念，並非全然正確。 此部份留待後續再做說明。

Also See

2006.12.14: 理解 dynamic loader 內部原理的幾個先備知識（一） 2006.12.15: .bss section 的觀念：uninitialized data section

]]> https://www.jollen.org/blog/2006/12/bss_section_2.html https://www.jollen.org/blog/2006/12/bss_section_2.html Linux Device Drivers & Kernel Fri, 15 Dec 2006 02:02:28 +0800 ，由程式碼的角度來看，就是「未初始化的變數」。我們直接以一段 code 來說明，讓大家更清楚這樣的概念。

#include <stdio.h>

int foo;
int bar;

int main(void)
{
   int *ptr;

   printf(".bss section starts at %08p\n", &foo);

   printf("foo is %d.\n", foo);

   ptr = &foo;
   *ptr = 12345;

   printf("foo is %d.\n", foo);
   printf(".bss section starts at %08p\n", &foo);

   return 0;
}

這段 code 相當簡單，但是隱含幾個重要的觀念，條列說明如下： 1. foo 是一個變數，在程式碼裡沒有被初始化（uninitialized），所以程式執行時（process），foo 變數會被擺在「.bss section」。 2. 同理，bar 變數也是。 3. foo 是第一個 uninitialized data，所以他的 virtual address，形同 .bss section 的開始位址（process virtual address）。 程式要實驗的項目如下： 1. 觀念 3. 的應用，我們印出 .bss section 的 start address。 2. foo 是全域變數，未初始化時的值是 0（zero）。 3. 用 '*ptr' 指向 .bss section 的 start address，此位址等於 foo 變數的值。 4. 把 .bss section 啟始位址處記憶體的值（value）改成 12345（透過 ptr 指標）。 沒搞錯的話，foo 變數的值就會變成 12345。 以下是執行結果：

# ./bss
.bss section starts at 0x8049588
foo is 0.
foo is 12345.
.bss section starts at 0x8049588

很特別的一個 section，值得深入研究。]]> https://www.jollen.org/blog/2006/12/bss_section_uninitialized_data.html https://www.jollen.org/blog/2006/12/bss_section_uninitialized_data.html Linux Device Drivers & Kernel Fri, 15 Dec 2006 01:11:24 +0800 接下來，即將啟動 ELF 格式的「execution view」介紹。本日記是進入「dynamic loader」前的準備工作「之一」。

果然是很大挑戰的研究。說明幾個注意事項如下。

必須了解 ELF 的格式觀念

「Executable and Linking Format」專欄已經把 ELF 格式的「linking view」做了初步的介紹，在此專欄裡，Jollen 針對 ELF 格式的概念以 loader v0.1~v0.5 共五個範例做說明。想要了解 ELF 格式的朋友，可以參考此專欄。

Section 的用途摘要說明

每個 section 都有不同的用途，在 SysV ABI 裡所定義的特殊 section 與其用途整理如下：

Section	用途
.bss	用來置放程式裡未初始化的資料（uninitialized data），當程式執行時預設會將這裡的資料初始化為0（zero）。
.comment	置放版本控制資訊。
.data	置放已初始化的資料（initialized data）
.data1	置放已初始化的資料（initialized data）
.debug	置放除錯時所使用資訊。
.dynamic	置放dynamic linking（動態連結）使用資訊。
.dynstr	置放dynamic linking所需的字串。
.dynsym	置放dynamic linking symbol table（動態連結符號表)
.fini	當程式正常結束後，系統會執行此section裡的程式碼。
.got	Global Offset Table
.hash	Symbol Hash Table
.init	當程式開始執行時，系統會在進入程式進入點前（C的main() 函數）執行此section裡的程式碼。
.interp	置放program interpreter（程式直譯器）的path name（路徑名稱）。
.line	置放編譯後的機器碼與原始程式之間的對應資訊，利用gdb 的list命令可以列出object file的原始程式碼，就是參考此 section的資訊。
.note	紀錄用section。
.plt	Procedure Linkage Table
.relname	置放relocation資訊。
.relaname	置放relocation資訊。
.rodata	置放read-only（唯讀）資料。
.rodata1	置放read-only（唯讀）資料。
.shstrtab	Section Name String Table。置放section的名稱字串。請參考本章範例程式的說明。
.strtab	Symbol table的string table。
.symtab	Symbol Table
.text	置放“text”資料，即可執行的程式指令。

前陣子「jserv」兄的深入淺出 Hello World的演講把 ELF 格式「執行時期」的作業系統行為做了很不錯的「整體概念」呈現，對於執行時期 ELF object file 的概念呈現，jserv 兄的簡報會比我接下來要分享的專欄更為細膩而且連貫。

整體觀念：jserv 兄的「深入淺出 Hello World Part I/II」

很精采的 ELF 執行時期系統行為的分享。

雖然準備 ELF 與 loader 的專欄花了不少時間，但是還是覺得寫的不好。原因是，對於這種必須深入系統內部細節的技術討論，「整體概念」的一次呈現是相當重要的。對於 ELF 執行時期系統行為的討論，我要推薦 jserv 兄的「深入淺出 Hello World」系列演講；對於整體的概念呈現，jserv 的簡報做的比我的專欄還要好。

知識若能分享，就不必重造車輪，開放源碼分享的是知識，而不是程式碼。Jollen 自己的「ELF 執行時間」專欄，整體的呈現方式一直拿不定主意，還好，直接以 jserv 兄分享的簡報做為藍本，就容易多了！

需要了解 Linux 的 Memory Management 嗎？

需要懂一點概念，但不用深入 kernel code。

Linux 的 memory management 並不是容易撰寫的題目，這道題目的規劃走向可以是「kernel code 導向」，也可以是「概念式導向」，前者以 kernel code 來說明，後者以圖解觀念的方式進行；前者的優點是具體而且可以很細微，但是考驗作者的功力，後者的優點是概念能清楚呈現，但細膩度不足。

我認為，一開始選擇「概念式導向」的呈現方式會比較適當，這應該也是大家比較可以接受的方式。

.bss 節區

這是一個很特殊的節區，「linking view」上，他不佔檔案空間、他用來存放「未初始化的變數」。Process（程式執行時）會具備這個特殊的節區。因此，我們只討論 .bss section 的「process virtual address」，而不討論「.bss section 所在的 file offset」。

之後再寫日記，以一段 code 來說明。

注記

• 2006.12.29: 調整標題。（Edited by Jollen）
]]> https://www.jollen.org/blog/2006/12/enabling_dynamic_loader_1.html https://www.jollen.org/blog/2006/12/enabling_dynamic_loader_1.html Linux Device Drivers & Kernel Thu, 14 Dec 2006 23:39:24 +0800 It looks like the newest version of the Linux kernel (2.6.20) will include KVM, the relatively new virtualization environment.」這篇 blog，kernel 2.6.20 已正式加入了 KVM 驅動程式，這也宣告 Linux 已經正式踏入「虛擬化（virtualization）」這個熱門的伺服器技術領域了。 Linux 的 kernel-space 虛擬機器驅動程式稱為「KVM」，KVM 於今年的 10 月 19 日首次正式發佈於 linux-kernel mailing list，並且於 11 月份時被 Linus 正式加入 kernel tree（根據此文）。這應該會是個有趣的好東西。

Also See

2006.10.19: Kernel 2.6 的 KVM (Kernel Virtual Machine) 驅動程式來了 2006.11.02: KVM 驅動程式的 HOWTO

]]> https://www.jollen.org/blog/2006/12/kvm_driver_coming.html https://www.jollen.org/blog/2006/12/kvm_driver_coming.html Linux Device Drivers & Kernel Tue, 12 Dec 2006 22:10:05 +0800 由本篇日記開始，我們將進行「Linux Device Driver 入門：I/O 處理」的議題討論。這裡所提的 I/O 處理定義是：user process 與 physical device 的 I/O 存取。

在讀「Linux Device Driver 入門：I/O 處理」專欄前，您必須熟悉 Linux 驅動程式的架構，因此「Linux Device Driver 入門：架構層」的專欄是 Jollen's Linux Device Driver 系列專欄的先備知識；此外，接下來的專欄使用的語法也必須對架構層有基本認識後才能看得懂。

Linux 驅動程式 I/O 機制

Linux device driver 處理 I/O 的「基本款」是：

• fops->ioctl

• fops->read

• fops->write

另外「典藏款」則是 mmap，未來在「Linux Device Driver 進階」專欄裡再來討論這個主題。

fops->ioctl

ioctl 代表 input/output control 的意思，故名思義，ioctl system call 是用來控制 I/O 讀寫用的，並且是支援 user application 存取裝置的重要 system call。因此，在Linux驅動程式設計上，我們會實作ioctl system call以提供user application讀寫（input/output）裝置的功能。

依此觀念，回到架構篇所舉的 debug card 範例。當 user application 需要將數字顯示到 debug card 時，範例 debug card 0.1.0 便需要實作 ioctl system call，然後在 fops->ioctl 裡呼叫 outb() 將 user application 所指定的數字輸出至 I/O port 80H。

User application 使用 GNU LIBC 的 ioctl() 函數呼叫device driver所提供的命令來「控制」裝置，因此驅動程式必須實作 fops->ioctl 以提供「命令」給使用者。

fops->read & fops->write

read/write 是 Linux 驅動程式最重要的 2 個 driver function，也是驅動程式最核心的觀念所在。對驅動程式而言，read/write 的目的是在實作並支援 user application 的 read() 與 write() 函數；user application 是否能正常由硬體讀寫資料，完全掌握在驅動程式的 read/write ethod。

User application 呼叫 read()/write() 函數後，就會執行 fops->read 與 fops->write。read/write method 負責讀取使用者資料與進行裝置的I/O 存取。依照觸發資料傳輸的方式來區分，我們可以將 I/O 裝置分成以下 2 種（from hardware view）：

•  Polling：I/O裝置不具備中斷。
•  Interrupt：I/O裝置以中斷觸發方式進行I/O。

根據I/O處理原理的不同（from software view），可以將 read/write method 的實作策略分成多種排列組合來討論。為了簡化討論內容，未來的日記將鎖定「Interrupt 式的 I/O」來做探討。

]]> https://www.jollen.org/blog/2006/12/inux_device_driver_io_1.html https://www.jollen.org/blog/2006/12/inux_device_driver_io_1.html Linux Device Drivers & Kernel Tue, 12 Dec 2006 12:02:30 +0800 修改了認證規定，自至再也沒有所謂的終生有效的 LPIC 證照了。前幾天 LPI 又發佈消息指出，明年一月將會開始發動 LPI 的最頂級認證「LPIC-3」。LPIC-3 的認證也籌畫好幾年了，終於在今天看到這則另人感動的消息。 由於 LPIC-3 是針對大型企業應用與 IT 專家、顧問等級的認證考試，能取得 LPIC-3 這種級數的認證，會是一種技術能力上的肯定；不過，LPIC-3 必須具備「有效」的 LPIC-1 與 LPIC-2 才能報考，所以尚未取得前二級的認證，或是證照過期的朋友，可要先做一下準備功課了。 原文報導在此：http://www.linux-watch.com/news/NS8820915301.html]]> https://www.jollen.org/blog/2006/12/lpic3.html https://www.jollen.org/blog/2006/12/lpic3.html 其它 Mon, 11 Dec 2006 23:22:15 +0800 AVR32 is a new high-performance 32-bit RISC microprocessor core, designed for cost-sensitive embedded applications, with particular emphasis on low power consumption and high code density. Linux for AVR32 架構的資訊可參考 The AVR32 Linux project 網站。AVR32 architecture 對於作業系統（operating system）的支援方面，除了必備的 MMU（Memory Management Unit）外，還有一個 MPU（Memory Protection Unit）單位。 MPU 允許 user 將記憶體空間切割成不同的「protection regions」，每個 region 的大小都是 user-defined 的，並且「starts at a user-defined address」。另外，節錄一小段 AVR32 architecture document 上對於 MPU 的說明如下：

The different regions can have different access privileges, cacheability attributes and bufferability attributes. The MPU does not perform any address translation.

因此，AVR32 架構文件提到，MPU 是簡單的 MMU，只是不做 address translation。]]> https://www.jollen.org/blog/2006/12/avr32_linux.html https://www.jollen.org/blog/2006/12/avr32_linux.html Linux Device Drivers & Kernel Sat, 09 Dec 2006 18:28:18 +0800 這本書沒有 step-by-step 的教學，也沒有類似「指令介紹」的條列說明。對於已經有「片斷實作經驗」的讀者來說，閱讀此書能快速得到「完整的領域知識」；會以「快速」來形容是因為這本書需要一些片斷的實作經驗，才能比較容易理解章節的關係與內文佈署，但是我特別喜歡這種風格的寫作，主要原因是能無痛且快速瀏覽完整的相關議題。 同時，這本書也能讓想學習 embedded Linux 的讀者清楚了解到 embedded Linux 所涉及的層面到底有多廣。]]> https://www.jollen.org/blog/2006/12/got_embedded_linux_primer.html https://www.jollen.org/blog/2006/12/got_embedded_linux_primer.html 其它 Thu, 07 Dec 2006 15:11:58 +0800 讓 kernel 常在我心：探討如何與 kernel 的發展同步」的日記，內容是大略介紹如何與 kernel 的發展同步（day-by-day）。 但是，如果並不是很需要每天去注意 kernel 的動態的話，只要在每個 kernel 穩定版（stable）釋出後去看 Changlog 就好了。特別是 kernel 2.6.1x 的更新項目（update）、臭蟲修正（big fix）、新的驅動程式與 filesystem 更是以可怕的「量」在 patch，特別是最近半年的 3 個 kernel 版本（2.6.17~19），變化量真是到了油門全開的狀態，所以每天看 kernel 會是沈重的負擔。 話說回來，改變是好事。期待的是，看著這麼多的改變與越來越多的新驅動程式加入，以及企業級（enterprise-class）功能的成熟，我們已經可以拿到越來越棒的「成熟」kernel 了。誠如 Linus 在 2.6.19 stable 釋出時的玩笑話「It's one of those rare 'perfect' kernels」。 言歸正傳，如果要 keep 新 kernel 做了什麼改變，或是了解「什麼功能在幾版的 kernel 才開始有」、「某些 bug 在幾版做修正」、「這個版本是否對理器架構面做修正」等，建議可以直接由 kernelnewbies.org 做查詢，例如，我想知道 kernel 2.6.17 改了什麼東西，就可以輸入以下的 URL： http://kernelnewbies.org/Linux_2_6_17 同理，我想知道幾天前才丟出來的 kernel 2.6.19 加了什麼、改了什麼，就輸入以下的 URL： http://kernelnewbies.org/Linux_2_6_19 就如前面提到的，kernel 2.6.1x 的修改變化相當大，特別是在 kernel 2.6.16（大約）後，每每都有重大更新，修正範圍也「波及」到「Kernel Core」。如果工作場合與 kernel 有關係，確實有必要仔細閱讀每一個版本的 Changelog。]]> https://www.jollen.org/blog/2006/12/linux_kernel_changelog_howto.html https://www.jollen.org/blog/2006/12/linux_kernel_changelog_howto.html Linux Device Drivers & Kernel Wed, 06 Dec 2006 22:15:54 +0800 開根號倒數 (InvSqrt(), 1 / sqrt(x)) 速算法」，標題讓我大感興趣，原來是一篇 slashdot 上的新聞，他們在找「開根號倒數」這個利害技巧的原作者，詳細介紹可看苦牢兄的 blog。Slashdot 的新聞所提到的「找人」過程在這裡：http://www.beyond3d.com/articles/fastinvsqrt/。 仔細閱讀的話發現還相當有趣，作者是誰最後仍然不可考，被點名的高手都說不是他幹的！不過最大的收獲是知道了一份「HAKMEM」的文件，這是在 60's 年代到 70's 年代初期，一群 MIT 的高手所記錄的程式寫作技巧（tricks）。 長久以來一直被「分層架構」與「抽象化設計」所教育著，便遺忘了這些原本才是「程式設計師」本質的數理應用，只能說 programmer 稱不上，充其量可能只是看文件寫 code 的 coding mahcine 吧。 另外，講到程式寫作技巧，就想到有趣的「解題」遊戲，又想到一位「冼鏡光」老師，冼老師的那本 C 名題精選著作是解題的必備好書。目前冼老師在 Michigan Technological University 教書，老師有個人首頁。]]> https://www.jollen.org/blog/2006/12/mit_programming_hakmem.html https://www.jollen.org/blog/2006/12/mit_programming_hakmem.html 其它 Wed, 06 Dec 2006 20:48:02 +0800 我們接續 loader v0.4 的工作，強化一下輸出結果的可讀性；先來比較一下 loader v0.4 與 loader v0.5 的輸出畫面。

$ ./loader-0.4 loader-0.4

$ ./loader-0.5 loader-0.4

ELF Identification Class: 32-bit objects Machine: Intel 80386 Num of secionts: 34 .interp .note.ABI-tag .hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .rodata .eh_frame .data .dynamic .ctors .dtors .jcr .got .bss .comment .debug_aranges .debug_pubnames .debug_info .debug_abbrev .debug_line .debug_frame .debug_str .shstrtab .symtab .strtab

ELF Identification Class: 32-bit objects Machine: Intel 80386 Name Size FileOff [01] .interp 19 244 [02] .note.ABI-tag 32 264 [03] .hash 56 296 [04] .dynsym 144 352 [05] .dynstr 98 496 [06] .gnu.version 18 594 [07] .gnu.version_r 32 612 [08] .rel.dyn 8 644 [09] .rel.plt 48 652 [10] .init 23 700 [11] .plt 112 724 [12] .text 1292 836 [13] .fini 27 2128 [14] .rodata 348 2156 [15] .eh_frame 4 2504 [16] .data 12 2508 [17] .dynamic 200 2520 [18] .ctors 8 2720 [19] .dtors 8 2728 [20] .jcr 4 2736 [21] .got 40 2740 [22] .bss 4 2780 [23] .comment 306 2780 [24] .debug_aranges 120 3088 [25] .debug_pubnames 37 3208 [26] .debug_info 2692 3245 [27] .debug_abbrev 312 5937 [28] .debug_line 636 6249 [29] .debug_frame 20 6888 [30] .debug_str 1722 6908 [31] .shstrtab 299 8630 [32] .symtab 1856 10292 [33] .strtab 1132 12148

Cool！做出了 'objdump -x' 的部份功能。頗為有趣，那麼用 objdump 來互相比較一下看看。

loader v0.5 v.s. objdump v.s. readelf

$ objdump -x loader-0.4（只擷取 section 輸出結果）

$ ./loader-0.5 loader-0.4

Sections: Idx Name Size VMA LMA File off Algn 0 .interp 00000013 080480f4 080480f4 000000f4 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .note.ABI-tag 00000020 08048108 08048108 00000108 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .hash 00000038 08048128 08048128 00000128 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .dynsym 00000090 08048160 08048160 00000160 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .dynstr 00000062 080481f0 080481f0 000001f0 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .gnu.version 00000012 08048252 08048252 00000252 2**1 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .gnu.version_r 00000020 08048264 08048264 00000264 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .rel.dyn 00000008 08048284 08048284 00000284 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 8 .rel.plt 00000030 0804828c 0804828c 0000028c 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 9 .init 00000017 080482bc 080482bc 000002bc 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 10 .plt 00000070 080482d4 080482d4 000002d4 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 11 .text 0000050c 08048344 08048344 00000344 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 12 .fini 0000001b 08048850 08048850 00000850 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 13 .rodata 0000015c 0804886c 0804886c 0000086c 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 14 .eh_frame 00000004 080489c8 080489c8 000009c8 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 15 .data 0000000c 080499cc 080499cc 000009cc 2**2 CONTENTS, ALLOC, LOAD, DATA 16 .dynamic 000000c8 080499d8 080499d8 000009d8 2**2 CONTENTS, ALLOC, LOAD, DATA 17 .ctors 00000008 08049aa0 08049aa0 00000aa0 2**2 CONTENTS, ALLOC, LOAD, DATA 18 .dtors 00000008 08049aa8 08049aa8 00000aa8 2**2 CONTENTS, ALLOC, LOAD, DATA 19 .jcr 00000004 08049ab0 08049ab0 00000ab0 2**2 CONTENTS, ALLOC, LOAD, DATA 20 .got 00000028 08049ab4 08049ab4 00000ab4 2**2 CONTENTS, ALLOC, LOAD, DATA 21 .bss 00000004 08049adc 08049adc 00000adc 2**2 ALLOC 22 .comment 00000132 00000000 00000000 00000adc 2**0 CONTENTS, READONLY 23 .debug_aranges 00000078 00000000 00000000 00000c10 2**3 CONTENTS, READONLY, DEBUGGING 24 .debug_pubnames 00000025 00000000 00000000 00000c88 2**0 CONTENTS, READONLY, DEBUGGING 25 .debug_info 00000a84 00000000 00000000 00000cad 2**0 CONTENTS, READONLY, DEBUGGING 26 .debug_abbrev 00000138 00000000 00000000 00001731 2**0 CONTENTS, READONLY, DEBUGGING 27 .debug_line 0000027c 00000000 00000000 00001869 2**0 CONTENTS, READONLY, DEBUGGING 28 .debug_frame 00000014 00000000 00000000 00001ae8 2**2 CONTENTS, READONLY, DEBUGGING 29 .debug_str 000006ba 00000000 00000000 00001afc 2**0 CONTENTS, READONLY, DEBUGGING

ELF Identification Class: 32-bit objects Machine: Intel 80386 Name Size FileOff [00] .interp 19 244 [01] .note.ABI-tag 32 264 [02] .hash 56 296 [03] .dynsym 144 352 [04] .dynstr 98 496 [05] .gnu.version 18 594 [06] .gnu.version_r 32 612 [07] .rel.dyn 8 644 [08] .rel.plt 48 652 [09] .init 23 700 [10] .plt 112 724 [11] .text 1292 836 [12] .fini 27 2128 [13] .rodata 348 2156 [14] .eh_frame 4 2504 [15] .data 12 2508 [16] .dynamic 200 2520 [17] .ctors 8 2720 [18] .dtors 8 2728 [19] .jcr 4 2736 [20] .got 40 2740 [21] .bss 4 2780 [22] .comment 306 2780 [23] .debug_aranges 120 3088 [24] .debug_pubnames 37 3208 [25] .debug_info 2692 3245 [26] .debug_abbrev 312 5937 [27] .debug_line 636 6249 [28] .debug_frame 20 6888 [29] .debug_str 1722 6908 [30] .shstrtab 299 8630 [31] .symtab 1856 10292 [32] .strtab 1132 12148

不過事情好像有點怪異，我們的 loader v0.5 怎麼在最後多出 3 個 section 呢？被附身了。

不過，原來是 objdump 不會把最後這 3 個 section 印出來啦，這 3 個 section 分別是：

1) .shstrtab：section header straing table

2) .symtab：symbol table

3) .strtab：string table

哇塞！原來 symbol table 藏在這裡啊。但是，如果我們改用 readelf 來讀 ELF，就可以看到完整的 ELF headers 了，而且輸出的畫面也比較具可讀性：

$ readelf -S loader-0.4

There are 34 section headers, starting at offset 0x22e4:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .interp           PROGBITS        080480f4 0000f4 000013 00   A  0   0  1
  [ 2] .note.ABI-tag     NOTE            08048108 000108 000020 00   A  0   0  4
  [ 3] .hash             HASH            08048128 000128 000038 04   A  4   0  4
  [ 4] .dynsym           DYNSYM          08048160 000160 000090 10   A  5   1  4
  [ 5] .dynstr           STRTAB          080481f0 0001f0 000062 00   A  0   0  1
  [ 6] .gnu.version      VERSYM          08048252 000252 000012 02   A  4   0  2
  [ 7] .gnu.version_r    VERNEED         08048264 000264 000020 00   A  5   1  4
  [ 8] .rel.dyn          REL             08048284 000284 000008 08   A  4   0  4
  [ 9] .rel.plt          REL             0804828c 00028c 000030 08   A  4   b  4
  [10] .init             PROGBITS        080482bc 0002bc 000017 00  AX  0   0  4
  [11] .plt              PROGBITS        080482d4 0002d4 000070 04  AX  0   0  4
  [12] .text             PROGBITS        08048344 000344 00050c 00  AX  0   0  4
  [13] .fini             PROGBITS        08048850 000850 00001b 00  AX  0   0  4
  [14] .rodata           PROGBITS        0804886c 00086c 00015c 00   A  0   0  4
  [15] .eh_frame         PROGBITS        080489c8 0009c8 000004 00   A  0   0  4
  [16] .data             PROGBITS        080499cc 0009cc 00000c 00  WA  0   0  4
  [17] .dynamic          DYNAMIC         080499d8 0009d8 0000c8 08  WA  5   0  4
  [18] .ctors            PROGBITS        08049aa0 000aa0 000008 00  WA  0   0  4
  [19] .dtors            PROGBITS        08049aa8 000aa8 000008 00  WA  0   0  4
  [20] .jcr              PROGBITS        08049ab0 000ab0 000004 00  WA  0   0  4
  [21] .got              PROGBITS        08049ab4 000ab4 000028 04  WA  0   0  4
  [22] .bss              NOBITS          08049adc 000adc 000004 00  WA  0   0  4
  [23] .comment          PROGBITS        00000000 000adc 000132 00      0   0  1
  [24] .debug_aranges    PROGBITS        00000000 000c10 000078 00      0   0  8
  [25] .debug_pubnames   PROGBITS        00000000 000c88 000025 00      0   0  1
  [26] .debug_info       PROGBITS        00000000 000cad 000a84 00      0   0  1
  [27] .debug_abbrev     PROGBITS        00000000 001731 000138 00      0   0  1
  [28] .debug_line       PROGBITS        00000000 001869 00027c 00      0   0  1
  [29] .debug_frame      PROGBITS        00000000 001ae8 000014 00      0   0  4
  [30] .debug_str        PROGBITS        00000000 001afc 0006ba 01  MS  0   0  1
  [31] .shstrtab         STRTAB          00000000 0021b6 00012b 00      0   0  1
  [32] .symtab           SYMTAB          00000000 002834 000740 10     33  54  4
  [33] .strtab           STRTAB          00000000 002f74 00046c 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

原來這是工具的問題。嗯！好吧，以後都改用 readelf 來玩吧。

Index 0: undefined

還有一點就是，ELF headers index 0 在 SysV ABI 裡的定義是「undefined」，readelf 把它輸出成 NULL，我們的範例跟 objdump 一樣，直接跳過！

readelf 輸出的其它 column 分述如下。

Type

「type」欄位的話就是在「ELF（Executable and Linking Format）格式教學文件, #7: 讀 ELF 的 Section Name（透過 strtab）」裡介紹到的 sh_type。

Addr

這個好玩，不過目前先跳過。（>_<）

Off、Size

跟我們的 loader v0.5 輸出結果一樣，分別代表 section 在 ELF object 裡的 file offset 與其大小（bytes）。readelf 是用十六進位輸出，我們的範例是用十進位輸出。

範例程式一樣可以由「http://tw.jollen.org/elf-programming/」下載。

Also See

2006.11.19: ELF（Executable and Linking Format）格式教學文件, #1: ELF 簡介 2006.11.22: ELF（Executable and Linking Format）格式教學文件, #2: ELF header 與範例規劃 2006.11.24: ELF（Executable and Linking Format）格式教學文件, #3: 第一個範例：loader v0.1（讀 ELF 檔頭） 2006.11.26: ELF（Executable and Linking Format）格式教學文件, #4: 第一個範例：loader v0.2（ELF Identification） 2006.11.28: ELF（Executable and Linking Format）格式教學文件, #5: 讀 ELF Section（說明） 2006.12.04: ELF（Executable and Linking Format）格式教學文件, #6: 讀 ELF Section（程式列表） 2006.12.04: ELF（Executable and Linking Format）格式教學文件, #7: 讀 ELF 的 Section Name（透過 strtab）

]]> https://www.jollen.org/blog/2006/12/_elfexecutable_and_linking_for.html https://www.jollen.org/blog/2006/12/_elfexecutable_and_linking_for.html GNU Toolchains & Linux Systems Programming Wed, 06 Dec 2006 01:12:10 +0800 根據 SysV ABI 的定義，若 section 的類型為 SHT_STRTAB，則該 section entry 即為 string table 的 section header。Section 的類型可由 section header 的 sh_type 欄位來判斷，SysV ABI 定義的 section 類型（sh_type）如下表所示。

表 sh_type 欄位的定義

Name	Value
SHT_NULL	0
SHT_PROGBITS	1
SHT_SYMTAB	2
SHT_STRTAB	3
SHT_RELA	4
SHT_HASH	5
SHT_DYNAMIC	6
SHT_NOTE	7
SHT_NOBITS	8
SHT_REL	9
SHT_SHLIB	10
SHT_DYNSYM	11
SHT_LOPROC	0x70000000
SHT_HIPROC	0x7fffffff
SHT_LOUSER	0x80000000
SHT_HIUSER	0xffffffff

我們在範例程式 loader-0.3.c 中，試著由一堆的 section 裡找出類型為 string table（SHT_STRTAB）的section。接下來程式 loader-0.4.c 將會試著實作讀取 ELF 的 string table，並將有 section 的名稱印出。

讀取 Section Name String Table

String table 是一個特殊的 section，此 section 紀錄所有 section 的名稱（ASCII 字串）。String table 是一個字元型別的陣列，每一個 section 都會有一個索引值來索引自己的 section name 字串，section header 的 sh_name 欄位則是存放了此索引值，如圖所示。



圖 ELF section name string table

接下來的範例程式將不再直接列表，請大家由 http://tw.jollen.org/elf-programming 下載。

程式說明

呼叫了 parse_sections() 函數來讀取section header table：

parse_sections(&f_header, fd);

相較於 loader-0.3.c 的 parse_sections() 函數，在 0.4 的版本裡，我們所做的改變如下：

1. 讀取 string table 的內容
2. 列印所有 section 的名稱

首先，我們新增一個陣列來存放 string table 的內容：

char strtab[65535];

接下來一樣讀取所有的 section entry，並且找出 string table：

   for (i = 0; i < hdr->e_shnum; i++) {
      read(fd, &header_ent[i], sizeof(Elf32_Shdr));

      /* load section name string table */
      if (i == hdr->e_shstrndx) {
         sh_strtab = &header_ent[i];
      }
   }

我們試著用另外一種方法來找出 string table 吧！根據 SysV ABI 的定義，string table 在 section header table 裡的 section entry index（索引值）紀錄在 ELF header 的 e_shstrndx 欄位，因此，我們判斷目前的 section header table 索引值是否等於 e_shstrndx 來找出 string table。接下來再讀取string table　的內容：

   /* read “String Table” */
   lseek(fd, sh_strtab->sh_offset, SEEK_SET);
   read(fd, strtab, sh_strtab->sh_size);

程式裡利用 lseek() 函數將檔案讀寫指標移 string table 開始的地方，然後再將整個 string table 讀出。要注意的是，section 的長度紀錄於 section header裡的 sh_size 欄位。最後再逐一將每個section的名稱列印在螢幕上：

   /* Index 0: undefined */
   for (i = 1; i < hdr->e_shnum; i++) {
      printf("%s\n", &strtab[header_ent[i].sh_name]);
   }

小結

我們知道一個很重要的觀念了。ELF section 的字串名稱是由 string table 查表得知，section 名稱在 string table 陣列裡的索引值則是紀錄在 section header 裡的 sh_name 欄位。

Also See

2006.11.19: ELF（Executable and Linking Format）格式教學文件, #1: ELF 簡介 2006.11.22: ELF（Executable and Linking Format）格式教學文件, #2: ELF header 與範例規劃 2006.11.24: ELF（Executable and Linking Format）格式教學文件, #3: 第一個範例：loader v0.1（讀 ELF 檔頭） 2006.11.26: ELF（Executable and Linking Format）格式教學文件, #4: 第一個範例：loader v0.2（ELF Identification） 2006.11.28: ELF（Executable and Linking Format）格式教學文件, #5: 讀 ELF Section（說明） 2006.12.04: ELF（Executable and Linking Format）格式教學文件, #6: 讀 ELF Section（程式列表）

]]> https://www.jollen.org/blog/2006/12/elfexecutable_and_linking_form.html https://www.jollen.org/blog/2006/12/elfexecutable_and_linking_form.html GNU Toolchains & Linux Systems Programming Mon, 04 Dec 2006 17:25:24 +0800 範例列表：loader v0.3

/*
 * Copyright(c) 2003,2006 www.jollen.org
 *
 * ELF programming. ver 0.3
 *
 */
#include <stdio.h>
#include <unistd.h>
#include <elf.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>

int elf_ident(char *ident)
{
   if (*(ident+EI_MAG0) != ELFMAG0) return 0;
   if (*(ident+EI_MAG1) != ELFMAG1) return 0;
   if (*(ident+EI_MAG2) != ELFMAG2) return 0;
   if (*(ident+EI_MAG3) != ELFMAG3) return 0;

   return -1;
}

void parse_ident(char *ident)
{
   printf("ELF Identification\n");

   printf("  Class:     ");
   switch (*(ident+EI_CLASS)) {
      case ELFCLASSNONE: printf("Invalid class\n"); break;
      case ELFCLASS32: printf("32-bit objects\n"); break;
      case ELFCLASS64: printf("64-bit objects\n"); break;
   }
}

void parse_machine(Elf32_Half machine)
{
   printf("Machine:     ");
   switch (machine) {
      case EM_NONE: printf("No machine\n"); break;
      case EM_M32: printf("AT&T WE 32100\n"); break;
      case EM_SPARC: printf("SPARC\n"); break;
      case EM_386: printf("Intel 80386\n"); break;
      case EM_68K: printf("Motorola 68000\n"); break;
      case EM_88K: printf("Motorola 88000\n"); break;
      case EM_860: printf("Intel 80860\n"); break;
      case EM_MIPS: printf("MIPS RS3000 Big-Endian\n"); break;

      default: printf("Unknow\n");
   }
}

void parse_sections(Elf32_Ehdr *hdr, int fd)
{
   int i;
   Elf32_Shdr header[40];
   Elf32_Shdr *strtab;          /* point to string table */

   printf("Num of secionts: %d\n", hdr->e_shnum);
   /* file offset of section header table */
   lseek(fd, hdr->e_shoff, SEEK_SET);

   for (i = 0; i < hdr->e_shnum; i++) {
      read(fd, &header[i], sizeof(Elf32_Shdr));

      /* find out string table ! */
      if (header[i].sh_type == SHT_STRTAB) strtab = &header[i];
   }
}

int main(int argc, char *argv[])
{
   int fd;
   Elf32_Ehdr f_header;

   if (argc != 2) {
      printf("Usage:    loader [filename]\n");
      return -1;
   }

   fd = open(argv[1], S_IRUSR);
   if (fd < 0) {
      printf("\nfile open error\n");
      return -1;
   }

   /* Read ELF Header */
   read(fd, &f_header, sizeof(Elf32_Ehdr));

   /* Parse header information */
   if (elf_ident(f_header.e_ident)) {
      parse_ident(f_header.e_ident);
      parse_machine(f_header.e_machine);
      parse_sections(&f_header, fd);
   } else {
      printf("not a ELF binary file\n");
   }

   close(fd);
}　

執行結果

$ ./loader-0.3 ./loader-0.3
ELF Identification
  Class:     32-bit objects
Machine:     Intel 80386
Num of secionts: 34

Also See

2006.11.19: ELF（Executable and Linking Format）格式教學文件, #1: ELF 簡介 2006.11.22: ELF（Executable and Linking Format）格式教學文件, #2: ELF header 與範例規劃 2006.11.24: ELF（Executable and Linking Format）格式教學文件, #3: 第一個範例：loader v0.1（讀 ELF 檔頭） 2006.11.26: ELF（Executable and Linking Format）格式教學文件, #4: 第一個範例：loader v0.2（ELF Identification） 2006.11.28: ELF（Executable and Linking Format）格式教學文件, #5: 讀 ELF Section（說明）

]]> https://www.jollen.org/blog/2006/12/executable_linking_format_elf_6.html https://www.jollen.org/blog/2006/12/executable_linking_format_elf_6.html GNU Toolchains & Linux Systems Programming Mon, 04 Dec 2006 16:39:25 +0800 規章原文」]]> https://www.jollen.org/blog/2006/12/lpi_certification_lpic.html https://www.jollen.org/blog/2006/12/lpi_certification_lpic.html 其它 Sun, 03 Dec 2006 23:09:26 +0800 unistd.h 是一個重要的標頭檔，裡頭是 system call 編號的定義；另外，linux/arch/i386/kernel/entry.S 則是每一個 system call 的進入點，也就是 system call table（位於 .data section）。

unistd.h也定義了處理不同參數個數的 system call handler，在這個標頭檔裡可以看到處理 0~6個參數的 handler（_syscall0~_syscall6）。例如以下是處理 1 個參數的handler：

#define _syscall1(type,name,type1,arg1) \
type name(type1 arg1) \
{ \
long __res; \
__asm__ volatile ("int $0x80" \
	: "=a" (__res) \
	: "0" (__NR_##name),"b" ((long)(arg1))); \
__syscall_return(type,__res); \
}

type, name分別為 system call的傳回值型別與函數名稱，例如呼叫 fork()，則此巨集展開後會變：

int fork(type 1 arg1)
{
…
}

　

]]> https://www.jollen.org/blog/2006/12/system_call_6_unistd_h.html https://www.jollen.org/blog/2006/12/system_call_6_unistd_h.html Linux Device Drivers & Kernel Fri, 01 Dec 2006 16:52:45 +0800 System call 是透過中斷來呼叫，而在 x86 系統的架構中，32-255 是所謂的 maskable interrupts 即使用者定義的中斷。Linux 在 i386 上實作system call可透過以下 2 個機制：

˙ lcall7/lcall27（call gates，呼叫閘道）
˙ int 0x80（software interrupt．軟體中斷）

Linux 應用程式使用 int 指令來觸發 0x80 號軟體中斷，其它作業系統像是 Solaris 的應用程式，則是使用 lcall7。在開機時，IDT是由arch/i386/kernel/traps.c:trap_init() 做初始化的設定：

void __init trap_init(void)
{
#ifdef CONFIG_EISA
if (isa_readl(0x0FFFD9) == 'E'+('I'<<8)+('S'<<16)+('A'<<24))
EISA_bus = 1;
#endif

#ifdef CONFIG_X86_LOCAL_APIC
init_apic_mappings();
#endif

set_trap_gate(0,&divide_error);
set_trap_gate(1,&debug);
set_intr_gate(2,&nmi);
set_system_gate(3,&int3); /* int3-5 can be called from all */
set_system_gate(4,&overflow);
set_system_gate(5,&bounds);
set_trap_gate(6,&invalid_op);
set_trap_gate(7,&device_not_available);
set_trap_gate(8,&double_fault);
set_trap_gate(9,&coprocessor_segment_overrun);
set_trap_gate(10,&invalid_TSS);
set_trap_gate(11,&segment_not_present);
set_trap_gate(12,&stack_segment);
set_trap_gate(13,&general_protection);
set_intr_gate(14,&page_fault);
set_trap_gate(15,&spurious_interrupt_bug);
set_trap_gate(16,&coprocessor_error);
set_trap_gate(17,&alignment_check);
set_trap_gate(18,&machine_check);
set_trap_gate(19,&simd_coprocessor_error);

set_system_gate(SYSCALL_VECTOR,&system_call);

/*
* default LDT is a single-entry callgate to lcall7 for iBCS
* and a callgate to lcall27 for Solaris/x86 binaries
*/
set_call_gate(&default_ldt[0],lcall7);
set_call_gate(&default_ldt[4],lcall27);

/*
* Should be a barrier for any external CPU state.
*/
cpu_init();

#ifdef CONFIG_X86_VISWS_APIC
superio_init();
lithium_init();
cobalt_init();
#endif
}

由以上的程式碼可以看出，0x80 號中斷向量會指到 system_call 進入點的位址。system_call 位於 arch/i386/kernel/entry.S：

ENTRY(system_call)
	pushl %eax			# save orig_eax
	SAVE_ALL
	GET_CURRENT(%ebx)
	testb $0x02,tsk_ptrace(%ebx)	# PT_TRACESYS
	jne tracesys
	cmpl $(NR_syscalls),%eax
	jae badsys
	call *SYMBOL_NAME(sys_call_table)(,%eax,4)
	movl %eax,EAX(%esp)		# save the return value
ENTRY(ret_from_sys_call)
	cli				# need_resched and signals atomic test
	cmpl $0,need_resched(%ebx)
	jne reschedule
	cmpl $0,sigpending(%ebx)
	jne signal_return

0x80 號中斷裡有很多 system call service routine，每個 system call service routine 的位址是經由 sys_call_table 查表得知。要呼叫 system call 時，必須告訴 Linux kernel 該 system call 的編號。System call 的編號透過 %eax 暫存器來傳遞給 Linux kernel。

例如 sys_open 這個 system call 的編號為 5。因此當我們呼叫 sys_open() 時，就要指定 %eax 暫存器的值為5。

]]> https://www.jollen.org/blog/2006/12/system_call_5.html https://www.jollen.org/blog/2006/12/system_call_5.html Linux Device Drivers & Kernel Fri, 01 Dec 2006 16:44:32 +0800 我們由之前的 hello.S 程式範例來做切入：

movl $len,%edx
movl $msg,%ecx
movl $1,%ebx
movl $4,%eax
int $0x80

System call 編號 4（%eax = 4）為 sys_write 函數，其原型宣告如下：

ssize_t sys_write(unsigned int fd, const char * buf, size_t count)

根據 sys_write 的參數宣告，我們必須傳遞參數如下：

˙ 第 1 個參數為 unsigned int fd，透過 %ebx 暫存器傳值。
˙ 第 2 個參數 const char * buf 透過 %ecx 暫存器傳遞位址（address）。
˙ 第 3 個參數 size_t count 透過 %edx 暫存器傳值。

這個部份的話嘛，大家不妨翻閱一下 Jollen 整理的 LSCT！

x86 的 Interrupt

x86的interrupt（中斷）可分別系統定義與使用者自訂：

˙ 中斷向量0~8、10~14、16~18：predefined interrupts and exceptions。
˙ 中斷向量19-31：保留。
˙ 中斷向量32-255：user-defined interrupts（maskable interrupts）。

每個中斷都有一個編號，稱為interrupt vector（中斷向量）；當中斷產生後，就會跳至相對應的interrupt handler執行程式。Interrupt handler程式的所在位址經由interrupt descriptor table（IDT）來得知。

Enternal interrupt、software interrupts與exception都是透過IDT來處理，IDT裡存放的是gate descriptor，gate descriptor的種類有：

˙ interrupt gate
˙ trap gate
˙ task gate

中斷的處理過程如下：

1. 中斷產生。

2. CPU根據interrupt vector來索引IDT裡的gate descriptor。

3. 如果 gate descriptor 是 interrupt gate，trap gate則以類似call gate方式呼叫handler procedure。如果是task gate，則透過task switch 來呼叫handler。



Interrupt gate與task gate的主要差別在於interrupt gate會將EFLAG的IP位元清除，而task gate則不會去變更IP位元。Linux不使用task gate。

]]> https://www.jollen.org/blog/2006/12/system_call_4.html https://www.jollen.org/blog/2006/12/system_call_4.html Linux Device Drivers & Kernel Fri, 01 Dec 2006 16:36:58 +0800 Wrapper routine 透過 0x80 號中斷（軟體中斷）進入 kernel space，並且跳至 system call handler執行。由於透過軟體中斷即可達成呼叫 system call的目地，因此使用 assembly來寫程式時，我們也可以直接呼叫system call。

在產生軟體中斷前，我們必須告訴 Linux kernel 所要呼叫的 system call 編號，system call 的編號透過 %eax 暫存器來指定；若要傳遞參數，則是透過其它暫存器來傳遞。

參數傳遞與傳回值

Linux system call最多可傳遞6個參數，參數的傳遞是透過以下的暫存器來完成：

• %ebx：第1個參數。
• %ecx：第2個參數。
• %edx：第3個參數。
• %esi：第4個參數。
• %edi：第5個參數。
• %ebp：第6個參數（做臨時用途）。

System call 的編號由 %eax 暫存器指定。System call 的傳回值則是存放於 %eax 暫存器。請看以下的範例程式 hello.S。

.data

msg:        .ascii	    "Hello, World!\n"
            len = . – msg

.text

            .global _start

_start:

# sys_write
	movl	    $len,%edx
	movl	    $msg,%ecx
	movl	    $1,%ebx
	movl	    $4,%eax
	int      $0x80

# sys_exit
	movl	    	$0,%ebx
	movl	    	$1,%eax
	int      $0x80　

組譯與連結的方法為：

$ as -o hello.o hello.S
$ ld -s -o hello hello.o

透過 assembly 程式，我們便能來初步了解 x86 上的 system call 架構。

]]> https://www.jollen.org/blog/2006/12/system_call_3_assembly_system.html https://www.jollen.org/blog/2006/12/system_call_3_assembly_system.html Linux Device Drivers & Kernel Fri, 01 Dec 2006 16:30:40 +0800 在 Linux system 底下，必須透過 GLIBC 裡的 system call function 來取得 kernel 的 system call 服務。

由 GLIBC 提供用來呼叫 system call 的函數稱為 wrapper function，wrapper function會呼叫 Linux kernel的handler routine，即 system_call() 函數。

呼叫 getpid() system call 的範例：

#include 
#include 
#include 

int main()
{
   pid_t self, parent;

   self = getpid();
   parent = getppid();

   printf("PID: %d, Parent PID: %d\n", (int) self, (int) parent);
   return 0;
}

利用 strace 工具可以追蹤程式所使用到的 system call：

$ strace ./pid
execve("./pid", ["./pid"], [/* 25 vars */]) = 0
uname({sys="Linux", node="jollen", ...}) = 0
brk(0)                                  = 0x80495ac
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40016000
open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=114793, ...}) = 0
old_mmap(NULL, 114793, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40017000
close(3)                                = 0
open("/lib/tls/libc.so.6", O_RDONLY)    = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`V\1B4\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1531064, ...}) = 0
old_mmap(0x42000000, 1257224, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x42000000
old_mmap(0x4212e000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x12e000) = 0x4212e000
old_mmap(0x42131000, 7944, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x42131000
close(3)                                = 0
set_thread_area({entry_number:-1 -> 6, base_addr:0x400169e0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
munmap(0x40017000, 114793)              = 0
getpid()                                = 970
getppid()                               = 969
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000
write(1, "PID: 970, Parent PID: 969\n", 26) = 26
munmap(0x40017000, 4096)                = 0
exit_group(0)                           = ?

由 strace 的輸出結果可以得知程式所呼叫的 system call，在這裡我們可以看到 getpid() 與 getppid()，並且也能得知 printf() 是基於 write() system call。

]]> https://www.jollen.org/blog/2006/12/system_call_2.html https://www.jollen.org/blog/2006/12/system_call_2.html Linux Device Drivers & Kernel Fri, 01 Dec 2006 16:24:50 +0800 System call 是 process 與作業系統之間的介面。System call 是由 Linux kernel 所實作並提供給使用者，user-space program 可透過 system call 與Linux kernel 溝通。以 C 語言來呼叫 system call 的話，則是透過 GLIBC（libc）來間接呼叫。

GLIBC 提供呼叫 system call 的介面稱為 wrapper routine，wrapper routine 會叫起 Linux 的 system call handler，最後再由 system call handler 找到service routine 的所在的位址，並交由 service routine 完成工作。整個流程如圖所示。



User program 與 wrapper routine 是 user-space 的 code，system call handler 與 service routine 則是屬於 kernel space。如圖，我們可以看到灰色的箭頭跨越一個鴻溝，代表著由 user space 進入 kernel space，在 i386 上這個動作是藉由中斷來達成。

]]> https://www.jollen.org/blog/2006/12/system_call_1.html https://www.jollen.org/blog/2006/12/system_call_1.html Linux Device Drivers & Kernel Fri, 01 Dec 2006 16:10:04 +0800 註冊頁面登記。 在註冊頁面有每一場 webinar 的時間與大綱。]]> https://www.jollen.org/blog/2006/12/timesys_webinar.html https://www.jollen.org/blog/2006/12/timesys_webinar.html Embedded Linux: Platforms and Applications Fri, 01 Dec 2006 15:48:37 +0800 OpenFirmware 只是一個規格，目前有 open source 的 OpenFirmware 專案，也就是知名的 OpenBIOS。當然也有商業性質的 OpenFirmware 實作，不過既然 IBM 也貢獻了 FCODE 給 OpenBIOS，那麼我想未來 OpenBIOS 絕對是首選的 OpenFirmware 實作了。 最後要說明的是，PReP 與 CHRP 都不是目前 Power Architecture 的 reference design 規格了。早先 Jollen 在「RISC 嵌入式平臺 (PowerPC) 的 VGA 解決方案」的日記裡也大略提到過 OpenBIOS 與 OpenFirmware（FCODE suite），大家也可以參考一下。 新一代的 Power Architecture 規格叫做 PAPR，這是由 Power.org 組織所制定的新規格，主要是針對 Power 架構的 workstation 與 server 所制定的（no PC...），目前的最新版本是 v2.0。]]> https://www.jollen.org/blog/2006/11/prep_chrp_openfirmware.html https://www.jollen.org/blog/2006/11/prep_chrp_openfirmware.html U-Boot , ARM9 and Pre-OS 相關 Wed, 29 Nov 2006 15:57:57 +0800 popularity-contest 統計資料來看，Debian ARM 已經超越 PowerPC 成為第三大的 Debian 架構分支。詳細報導在此。 讓 Debian ARM 成為第三熱門的 Debian 版本的功臣就是今年大大有名的 NSLU2 計畫，如果您還不曉得 NSLU2 的名號，可以到NSLU2 的官方網站瞧瞧。當初 NSLU2 計畫發起時，便立下這樣的志願（節錄自 LinuxDevices.com 的報導）：

to have the Linksys NSLU2 become a fully supported mainstream Linux distribution device.

這個目標達成了！Debian ARM 從第七名竄升到第三名，只花了九個月的時間；並且，有 90% 的 Debian ARM 使用者都是將 Debian ARM 安裝在 Linksys 的 NSLU2 device 上（節錄自 LinuxDevices.com 的報導）：

Ninety percent of those ARM installations are NSLU2 devices.

NSLU2 是今年 open source community 發展模式中，具代表性的成功案例之一。Jollen 認為，當中最關鍵的因素除了眾所矚目的開放源碼社群模式外，有二項關鍵因素是值得推敲思考的： 1. 將 Linksys NSLU2 當做是「device」來推廣，而不是「product」。如果你到 NSLU2 的首頁去，一定能看到這句話：「Purchase a Linksys NSLU2 and join our community if you are interested in doing the same.」。 東西當做 device 來賣，顧客是 community，賣了東西也得到不少東西；再說，賣給 community 的數量也不見得比賣 product 給 end-user 少。 2. NSLU2 device 拿來給社群做發展與「把玩」並建立自己的 open source project（與 community）後，才能得到其他（、更多） community 的支持，更多社群跟你互補後，不但能加快本身的產品發展速度與進行更有效的推廣，也能吸引許多「end-user」的關注。對於「product」的長期發展絕對是正面的。我們可以看到，許多社群的開發者（developer）都是熱血的死忠擁護者，這些人也是很好的 promoter。 Debian ARM（或 NSLU2）之所以成功，在 LinuxDevices.com 上的報導裡已經講出重點了：

This is, of course, the outcome of a lot of hard work by a lot of people, including (but not limited to) the NSLU2-Linux core team and developers, the OpenEmbedded developers, the Debian-arm porters, and the Debian-installer and Debian-kernel teams.

可見閉門造車並不是好事，因為除了要不停的「重造車輪」外，也無法讓不同的社群響應你的計畫，或是跟你互補。 ]]> https://www.jollen.org/blog/2006/11/debian_arm_nslu2_community.html https://www.jollen.org/blog/2006/11/debian_arm_nslu2_community.html Embedded Linux: Platforms and Applications Wed, 29 Nov 2006 09:18:13 +0800 今天的內容「讀取 ELF section」是這系列 ELF 文章的重點戲。因為我們終於進入 ELF 的核心議題「節區的觀念」了。在 loader v0.5 以前的範例，都是屬於靜態的討論（linking view）；在 loader v0.6 開始的討論中，我們將會開始提到動態的執行行為（execution view）。

如何讀取 ELF Section

我們分 2 個步驟來讀取 ELF 的 section 資訊：

1. 如圖一，一開始先讀取 section header table 的資訊。section header table 是所有 section 的紀錄表格，所有的 section 都要透過 section header table 才能得知其在檔案中的偏移位置（offset），如此一來才能讀取 section 的內容。

2. 如圖二，接著再根據 section header table 讀取檔案裡的每一個 section。

section header table 裡的 section 個數（section entries）紀錄於 ELF header 裡的 e_shnum 欄位，每個 section entry 的長度則是紀錄在 ELF header 的 e_shentsize 欄位，單位是bytes。


圖一：Section Header Table

ELF header 裡的 e_shoff 欄位，是 section header table 開始的檔案偏移位置 （file offset）。因此，我們只要由 e_shoff 偏移值開始讀取 e_shnum 個單位，每個單位為 e_shentsize（bytes），即可將整個 section header table 讀取出來。


圖二：Section Entries

SysV ABI 定義 section entry 的資料結構如下：

typedef struct {
  Elf32_Word	sh_name;
  Elf32_Word	sh_type;
  Elf32_Word	sh_flags;
  Elf32_Addr	sh_addr;
  Elf32_Off	sh_offset;
  Elf32_Word	sh_size;
  Elf32_Word	sh_link;
  Elf32_Word	sh_info;
  Elf32_Word	sh_addralign;
  Elf32_Word	sh_entsize;
} Elf32_Shdr;

Section header table 是 Elf32_Shdr data type 的陣列，其元素個數為 e_shnum，我們可以透過索引 Elf32_Shdr 陣列來讀取所有的 section，如圖二所示。

Section header（Elf32_Shdr）的欄位用途說明如下表。

Field	Description
sh_name	section的名稱，需由string table查表取得。
sh_type	section的類型。
sh_flags	section的屬性。
sh_addr	section在記憶體裡的起始位址，但並非所有的section都會被載入至記憶體。
sh_offset	section在objct file裡的開始偏移值（offset），程式必須根據此欄位來讀取section的本文。
sh_size	section的長度（bytes）。
sh_link	可用來存放section header table的index link。
sh_info	可用來存放section的額外資訊。
sh_addralign	紀錄section的address alignment，例如有些section的 alignment為DWORD（dobuleword）。
sh_entsize	有些section的內容為entry長度固定的table，例如symbol table。此欄用來紀錄entry的長度，單位是bytes。

範例程式：loader v0.3

接著說明 loader v0.2 需要改寫的功能。

在主程式新增一個 parse_sections() 函數來讀取 ELF object file 的 section header table：

parse_sections(&f_header, fd);

parse_sections() 負責做2件工作：

1. 讀取 Section Header Table

2. 找出 Section Name String Table

同時，在主程式也要加入以下 2 個變數：

Elf32_Shdr header[40];
Elf32_Shdr *strtab; /* point to string table */

header[] 用來存放由 section header table 所讀取出來的所有 section entry，其型別為 Elf32_Shdr；strtab 指標用來指向 section name string table，其型別為 Elf32_Shdr。Section name string table 是一個特殊的 section，下一個範例再來處理這個 section。

將檔案讀寫指標移到 e_shoff 的地方，準備開始讀取 section header table：

lseek(fd, hdr->e_shoff, SEEK_SET);

然後再利用最簡單的方式，一次一個將所有的section entry讀取出來，並且判斷該section entry是否為string table：

   for (i = 0; i < hdr->e_shnum; i++) {
      read(fd, &header[i], sizeof(Elf32_Shdr));

      /* find out string table ! */
      if (header[i].sh_type == SHT_STRTAB) strtab = &header[i];
   }

最後，section 用途是根據他的類型來區分的，這個部份留待下次再做說明。

Also See

2006.11.19: ELF（Executable and Linking Format）格式教學文件, #1: ELF 簡介 2006.11.22: ELF（Executable and Linking Format）格式教學文件, #2: ELF header 與範例規劃 2006.11.24: ELF（Executable and Linking Format）格式教學文件, #3: 第一個範例：loader v0.1（讀 ELF 檔頭） 2006.11.26: ELF（Executable and Linking Format）格式教學文件, #4: 第一個範例：loader v0.2（ELF Identification）

]]> https://www.jollen.org/blog/2006/11/elfexecutable_and_linking_form.html https://www.jollen.org/blog/2006/11/elfexecutable_and_linking_form.html GNU Toolchains & Linux Systems Programming Tue, 28 Nov 2006 17:14:49 +0800 embedded linux    wince    embedded system   
結果 embedded linux 跟 embedded system 的關係相當密切，幾乎是貼在一起走的。至於跟 wince 做比較的話，則是保持一定的差距，看起來跟幾年前相差不遠。 再來是「embedded linux」PK「王建民」：

embedded linux 王建民   

2005 年 Q1 以前，「王建民」幾乎是躺平的，大概只有 2004 Q3 亞洲盃時凸起來一下下。然後 2005 年 Q1 上大聯盟後是上市密月期，連拉數日長紅，接著到 2005 Q4 ~ 2005 Q1 是 MLB 休兵期間，再度躺平。 今年隨著 Wang 40 的精采表現而呈現的多頭走勢，沒想到在 Wang 40 回國後進入主升段，連爆長紅。雖然在 Wang 40 上市後，這期間有幾次紅線超越「Emebdded Linux」，不過這次 Wang 40 的主升段展開後，已經把「Embedded Linux」遠遠抛在腦後了。 如果再看下半部的新參考頁面「量」，Wang 40 老早就不把 embedded Linux 看在眼裡了。另外，如果你在 Google 找「王建民」，會發現右半部很「台灣味」： 王建民，加油！ ]]> https://www.jollen.org/blog/2006/11/embedded_linux_3.html https://www.jollen.org/blog/2006/11/embedded_linux_3.html 其它 Tue, 28 Nov 2006 14:00:27 +0800 ELF Identification

ELF header 資料結構裡的 e_ident 欄位用來判斷檔案是否為ELF格式的欄位，e_ident 欄位是一個陣列資料結構，其長度由 SysV ABI所定義的常數 EI_NIDENT指定。

EI_NIDENT 的值為 16 代表 e_ident 欄位有 16 個元素，SysV ABI 定義了 8 個常數來索引 e_ident 陣列的元素。

表 e_ident[] 索引值定義

Name	Value	說明
EI_MAG0	0	ELF 識別字元
EI_MAG1	1	ELF 識別字元
EI_MAG2	2	ELF 識別字元
EI_MAG3	3	ELF 識別字元
EI_CLASS	4	檔案類別 (class)
EI_DATA	5	資料編碼方式 (Data encoding)
EI_VERSION	6	檔案版本
EI_PAD	7	padding bytes 的開頭

loader-0.2.c主要的改變在於加入了判斷檔案是否為 ELF 格式的程式碼。要判斷檔案是否為 ELF 格式，必須根據 e_ident[] 裡的識別字元來做判斷：

• e_ident[EI_MAG0] 必須等於 ELFMAG0

• e_ident[EI_MAG1] 必須等於 ELFMAG1

• e_ident[EI_MAG2] 必須等於 ELFMAG2

• e_ident[EI_MAG3] 必須等於 ELFMAG3

表 ELF識別字元（magic number）定義

Name	Value	說明
ELFMAG0	0x7f	e_ident[EI_MAG0] 之值
ELFMAG1	‘E’	e_ident[EI_MAG1] 之值
ELFMAG2	‘L’	e_ident[EI_MAG2] 之值
ELFMAG3	‘F’	e_ident[EI_MAG3] 之值

判斷是否為 ELF 格式

設計一個 elf_ident() 函數來判斷檔案是否為 ELF 格式，其程式碼如下：

int elf_ident(char *ident)
{
   if (*(ident+EI_MAG0) != ELFMAG0) return 0;
   if (*(ident+EI_MAG1) != ELFMAG1) return 0;
   if (*(ident+EI_MAG2) != ELFMAG2) return 0;
   if (*(ident+EI_MAG3) != ELFMAG3) return 0;

   return -1;
}

e_ident[] 裡還存放許多 ELF 的資訊。以下再舉一例，我們新增一個函數 parse_ident() 來分析 e_ident[] 的 "CLASS" 資訊：

void parse_ident(char *ident)
{
   printf("ELF Identification\n");

   printf("  Class:	");
   switch (*(ident+EI_CLASS)) {
      case ELFCLASSNONE: printf("Invalid class\n");
             break;
      case ELFCLASS32: printf("32-bit objects\n");
            break;
      case ELFCLASS64: printf("64-bit objects\n");
            break;
   }
}

程式列表：loader-0.2.c

/*
 * Copyright(c) 2003,2006 www.jollen.org
 *
 * ELF programming. ver 0.2
 *
 */
#include 
#include 
#include 
#include 
#include 
#include 

int elf_ident(char *ident)
{
   if (*(ident+EI_MAG0) != ELFMAG0) return 0;
   if (*(ident+EI_MAG1) != ELFMAG1) return 0;
   if (*(ident+EI_MAG2) != ELFMAG2) return 0;
   if (*(ident+EI_MAG3) != ELFMAG3) return 0;

   return -1;
}

void parse_ident(char *ident)
{
   printf("ELF Identification\n");

   printf("  Class:	");
   switch (*(ident+EI_CLASS)) {
      case ELFCLASSNONE: printf("Invalid class\n"); break;
      case ELFCLASS32: printf("32-bit objects\n"); break;
      case ELFCLASS64: printf("64-bit objects\n"); break;
   }
}

void parse_machine(Elf32_Half machine)
{
   printf("Machine:	");
   switch (machine) {
      case EM_NONE: printf("No machine\n"); break;
      case EM_M32: printf("AT&T WE 32100\n"); break;
      case EM_SPARC: printf("SPARC\n"); break;
      case EM_386: printf("Intel 80386\n"); break;
      case EM_68K: printf("Motorola 68000\n"); break;
      case EM_88K: printf("Motorola 88000\n"); break;
      case EM_860: printf("Intel 80860\n"); break;
      case EM_MIPS: printf("MIPS RS3000 Big-Endian\n"); break;
       
      default: printf("Unknow\n");
   }
}

int main(int argc, char *argv[])
{
   int fd;
   Elf32_Ehdr f_header;

   if (argc != 2) {
      printf("Usage:	loader [filename]\n");
      return -1;
   }

   fd = open(argv[1], S_IRUSR);
   if (fd < 0) {
      printf("\nfile open error\n");
      return -1;
   }

   /* Read ELF Header */
   read(fd, &f_header, sizeof(Elf32_Ehdr));

   /* Parse header information */
   if (elf_ident(f_header.e_ident)) {
      parse_ident(f_header.e_ident);
      parse_machine(f_header.e_machine);
   } else {
      printf("not a ELF binary file\n");
   }
}

Also See

2006.11.19: ELF（Executable and Linking Format）格式教學文件, #1: ELF 簡介 2006.11.22: ELF（Executable and Linking Format）格式教學文件, #2: ELF header 與範例規劃 2006.11.24: ELF（Executable and Linking Format）格式教學文件, #3: 第一個範例：loader v0.1（讀 ELF 檔頭）

]]> https://www.jollen.org/blog/2006/11/executable_linking_format_elf_4.html https://www.jollen.org/blog/2006/11/executable_linking_format_elf_4.html GNU Toolchains & Linux Systems Programming Sun, 26 Nov 2006 12:27:02 +0800 ELF 的第一個範例：loader v0.1

ELF header 儲存執行檔的重要資訊，我們必須先知道如何讀取 ELF 檔案的檔頭資訊（header），才能處理個別節區（section）。在 GNU/Linux 系統下，程式可以直接引用 elf.h 標頭檔。完整的程式範例 loader-0.1.c 列表如下。

/*
 * Copyright (C) 2003 www.jollen.org
 *
 * ELF programming. ver 0.1
 *
 */
#include <stdio.h>
#include <unistd.h>
#include <elf.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>

void parse_machine(Elf32_Half machine)
{
   printf("Machine:	");
   switch (machine) {
      case EM_NONE: printf("No machine\n"); break;
      case EM_M32: printf("AT&T WE 32100\n"); break;
      case EM_SPARC: printf("SPARC\n"); break;
      case EM_386: printf("Intel 80386\n"); break;
      case EM_68K: printf("Motorola 68000\n"); break;
      case EM_88K: printf("Motorola 88000\n"); break;
      case EM_860: printf("Intel 80860\n"); break;
      case EM_MIPS: printf("MIPS RS3000 Big-Endian\n"); break;
       
      default: printf("Unknow\n");
   }
}

int main(int argc, char *argv[])
{
   int fd;
   Elf32_Ehdr f_header;

   if (argc != 2) {
      printf("Usage:	loader [filename]\n");
      return -1;
   }

   fd = open(argv[1], S_IRUSR);
   if (fd < 0) {
      printf("\nfile open error\n");
      return -1;
   }

   /* Read ELF Header */
   read(fd, &f_header, sizeof(Elf32_Ehdr));

   /* Parse header information */
   parse_machine(f_header.e_machine);
}

範例說明

程式 loader-0.1.c 首先宣告變數 f_header 用存放所讀取的檔頭資料：

Elf32_Ehdr f_header;

Elf32_Ehdr 的宣告在 elf.h 裡，這個 data type 是 SysV ABI 裡的 ELF object files 檔頭的標準資料結構。讀者的方式如同傳統的 C 語言一般，只要利用低階 I/O 函數將檔頭的部份讀出即可：

read(fd, &f_header, sizeof(Elf32_Ehdr));

目前我們只讀取 ELF header 的部份。ELF header 裡存放許多重要的 object file 資訊，其中一項為 e_machine 成員，因此程式接著來判斷此欄位的內容，並且列印出 object file 所支援的硬體平臺名稱。

在 parse_machine() 裡頭，我們判斷 e_machine 欄位的值，並且列印出相對應的硬體平臺名稱，例如：若 e_mahcine 的值為 EM_386，則印出 "Intel 80386" 字串。EM_386 與其它相關的常數都定義在 SysV ABI 標準裡，可在 elf.h 裡看到。這部份就留給大家當功課了。

執行結果

先將上面的程式碼 copy 下來存成 loader-0.1.c 後編譯成執行檔：

$ gcc -o loader-0.1 loader-0.1.c

接著再用 loader-0.1 來分析 ELF object file：

# ./loader-0.1 /bin/vi
Machine:        Intel 80386

Also See

2006.11.19: ELF（Executable and Linking Format）格式教學文件, #1: ELF 簡介 2006.11.22: ELF（Executable and Linking Format）格式教學文件, #2: ELF header 與範例規劃

]]> https://www.jollen.org/blog/2006/11/executable_linking_format_elf_3.html https://www.jollen.org/blog/2006/11/executable_linking_format_elf_3.html GNU Toolchains & Linux Systems Programming Fri, 24 Nov 2006 00:06:02 +0800 lsct_gen-0.1.tar.bz2（10 KBytes）]。另外，這個 script 也會把 system call 所在的檔案印出來。 這個版本只適合用來處理 2.6 系列的程式碼，無法處理 2.4 系列的 kernel source code。]]> https://www.jollen.org/blog/2006/11/lsct_gen.html https://www.jollen.org/blog/2006/11/lsct_gen.html GNU Toolchains & Linux Systems Programming Thu, 23 Nov 2006 19:12:24 +0800 本文接續之前的日記「ELF（Executable and Linking Format）格式教學文件, #1: ELF 簡介」，在了解 ELF 的用途後，再來我們先由「ELF Header」的部份開始看起，我們的目標是寫一個可以將 ELF 執行檔裡所有 section 讀取出來的程式。未來將繼續朝 user-space 的 ELF 處理前進。

如果您是 Jollen 的讀者，或許曾經在書上讀到這個章節，本系統的內容與書上內容大致相仿，但仍有一些小差異，建議您可再讀一次。我希望能以其它的出版形式，將這些內容都與大家分享。

ELF header：檔頭格式

ELF 於 SysV ABI 標準中定義，其中 ELF header 的結構如下表：

Field	Description
e_ident	用來辨別檔案是否為ELF，並包含一些machine independent 的資料。
e_type	檔案的類型
e_machine	檔案的平臺
e_version	版本資訊
e_entry	程式的起始位址（process virtual address）
e_phoff	program header table的檔案偏移值（offset），單位是bytes。如果沒有program header table則此值為0。
e_shoff	section header table的檔案偏移值（offset），單位是bytes。如果沒有section header table則此值為0。
e_flags	與processor有關的旗標值
e_ehsize	ELF header的長度，單位是bytes。
e_phentsize	program header table每個entry的長度（bytes），每個entry的長度都相等。
e_phnum	program header table的entry個數，若無program header table 則此欄的值為0。
e_shentsize	section header table每個entry的長度（bytes），每個entry的長度都相等。
e_shnum	section header table的entry個數，若無program header table則此欄的值為0。
e_shstrndx	section header table的index值，索引至section name string table entry。如果檔案沒有section name string table，則此欄的值為SHN_UNDEF。

ELF 檔案格式最基本的就是它的檔頭（header）部份，ELF header 儲存 object file 的各種資訊。ELF header 的讀取方式非常簡單，我們將會實作讀取 ELF header 的程式，以強化我們所讀到的觀念。

ELF header 的資料結構定義在 elf.h 裡，如下：

/* The ELF file header.  This appears at the start of every ELF file.  */

#define EI_NIDENT (16)

typedef struct
{
  unsigned char e_ident[EI_NIDENT];     /* Magic number and other info */
  Elf32_Half    e_type;                 /* Object file type */
  Elf32_Half    e_machine;              /* Architecture */
  Elf32_Word    e_version;              /* Object file version */
  Elf32_Addr    e_entry;                /* Entry point virtual address */
  Elf32_Off     e_phoff;                /* Program header table file offset */
  Elf32_Off     e_shoff;                /* Section header table file offset */
  Elf32_Word    e_flags;                /* Processor-specific flags */
  Elf32_Half    e_ehsize;               /* ELF header size in bytes */
  Elf32_Half    e_phentsize;            /* Program header table entry size */
  Elf32_Half    e_phnum;                /* Program header table entry count */
  Elf32_Half    e_shentsize;            /* Section header table entry size */
  Elf32_Half    e_shnum;                /* Section header table entry count */
  Elf32_Half    e_shstrndx;             /* Section header string table index */
} Elf32_Ehdr;

Section 與 section header table 的讀取與處理方式，會在介紹完 ELF header 後再做說明。

ELF 的範例程式

本系列日記共有 5 個範例程式，其功能差異整理如下表。

	讀取檔頭	分析檔頭	判斷ELF	處理Section	讀取Strtab	列印節區名稱
loader-0.1.c	●	●
loader-0.2.c	●	●	●
loader-0.3.c	●	●	●	●
loader-0.4.c	●	●	●	●	●	●
loader-0.5.c	●	●	●	●	●	●

為了能了解ELF格式，我們將會實作 6 大項功能如下：

1. 讀取檔頭：讀取 ELF 檔案的檔頭資訊。

2. 分析檔頭：分析讀取的檔頭資訊，例如分析 ELF 執行檔的編碼平臺。

3. 判斷 ELF：判斷所讀取的檔案是否為標準 ELF 格式的檔案。

4. 處理 Section：可以讀取所有 section 的資訊，並做簡單處理，例如找出是 string table 的 section。

5. 讀取 StrTab：讀取 section name string table 裡的資訊。

6. 列印節區名稱：處理 section name string table，可以根據 section name string table 來列印所有 section的名稱（ASCII string）。

我們將會以漸進式的方式來慢慢完成所有的功能，不同版本範例程式間的主要差異將會特別做說明，並詳細解釋新功能的程式實作。

另外，loader-0.4.c 與 loader-0.5.c 看似功能相同，但 loader-0.5.c 主要是為了討論 loader-0.4.c 裡幾個奇怪的地方。我們會在講解loader-0.5.c 程式時再做更詳細的說明。

Loader 在載入 object file 前，必須先由 ELF header 取得 object file 的資訊並且判斷 object file 是否為 ELF 格式的執行檔，然後才能將 object file 載至記憶體。

Also See

2006.11.19:  ELF（Executable and Linking Format）格式教學文件, #1: ELF 簡介

]]> https://www.jollen.org/blog/2006/11/executable_linking_format_elf_2html.html https://www.jollen.org/blog/2006/11/executable_linking_format_elf_2html.html GNU Toolchains & Linux Systems Programming Wed, 22 Nov 2006 23:39:19 +0800 從事 Embedded Linux（GNU/Linux systems on devices）工作的朋友，除了日常的讀書功課外，另外一個重要的工作就是「隨時注意 Linux kernel 的發展狀況」。要能與 Linux kernel 的發展同步，嚴格來說，已經是一件吃重的工作了，不過還是可以列出幾個基本的工作原則如下：

1. 每天閱讀 linux-kernel 郵遞論壇（mailing-list）的「標題」。

2. 隨時上 kernel.org 看看最新釋出的 kernel 版本（或留意 linux-kernel-announce mailing-list）。

3. 閱讀釋出版本的 Changelog。

4. 不要與 git 系統的距離太遠，定時看看 git 系統，保持一定的「短距離」。

Mailing List

linux-kernel 上的 posts 每天的量大約在 200~350 篇左右，數量並不算少，要把每一篇都看過是不太可能的，因此以我自己的閱讀心態來說，我會建議以下的閱讀方式：

1. 看標題，如果是自己有興趣或正在留意的更新，我就會標記下來持續追蹤。

2. 如果有 Bugfix 的 patch 出現，我會看看這項修正的起因與原理，但為了不讓自己花費太多時間，如果我對這項 patch 的修正「原理」不甚熟悉，我便會跳過此 post。

以下是閱讀 linux-kernel list 必須知道的幾件事：

1. 如果有新的修正，第一時間都會發佈在此 list 上，並且標題的起頭一定是 "[PATCH n/m] subject" 這樣的格式。PATCH 表示這是一個 patch 的發佈，由於一個 patch 會以多篇 post 發佈，因此就用「n/m」來表示「這是第幾篇 patch，總共有幾篇。」，例如：

[PATCH 0/7] KVM: Kernel-based Virtual Machine
[PATCH 1/7] KVM: userspace interface
[PATCH 2/7] KVM: Intel virtual mode extensions definitions
[PATCH 3/7] KVM: kvm data structures
[PATCH 5/7] KVM: mmu virtualization
[PATCH 6/7] KVM: x86 emulator
[PATCH 7/7] KVM: plumbing

2. 不能在這裡詢問與 kernel 發展無關的問題，例如：工具的使用、系統設定、詢問是否有XXX驅動程式、請求協助測試等等，這些都是不能張貼的文章。另外，原本就該留意的非成文禮節一定要注意，像是 FAQ 能找到的東西，就不要去麻煩人家。

3. list 裡大部份都是 device driver 的討論，並且很多都是架構面或觀念面的討論與修正建議，所以當您參與討論時，千萬不要用「個人的主觀看法，或是沒有事實與理論根據」的角度發表意見；由於「觀念」的修正是 kernel 2.6 驅動程式的大討論方向，所以必須先把主題相關的東西先看懂看熟後再參與討論。

kernel.org

我會不定時來看看最新發佈的 kernel 版本，因此我們必須知道目前仍在維護的 kernel 版本與其分支狀況，大致說明如下：

1. 2.6 與 2.4 都是目前仍持續積極維護中的版本。以本文寫作的時間為例（2006/11/20），目前最新的版本分別是 2.6.18.3（2006/11/19 釋出）與 2.4.33.4（2006/11/19 釋出）。

2. 2.4 的釋出版本有「stable」與「prepatch」二個分支。

3. 2.6 的釋出版本有「stable」、「prepatch」、「snapshot」與「-mm patch」四個分支。

其中 '-mm' 系列的 2.6 kernel 是由 Andrew Morton 所釋出的 Linux 分支，主要性質以「實驗」與「新功能」為主 ，所以常常可以在這個分支的 kernel 裡找到不久前才剛發佈在 mailing-list 上的 patch。如果您不太知道怎麼處理 mailing-list 上的 patch 發佈，也可以等 -mm patch 的發佈。

另外，prepatch 就是所謂的 '-rc' 發佈，所以檔名會接 '-rc?' 字串，例如：linux-2.6.19-rc6。

Changlog

每個在 kernel.org 上所釋出的 kernel 都會有一份變更紀錄（change logs）的檔案，可以了解這個版本與分支的釋出做了什麼變更。

上到 kernel.org 後，每個釋出版本的後面，會有 4 個選項（視版本不同）：

• F = full source
• V = view patch
• VI = view incremental
• C = current changesets

把「C」給按下去就會進到所謂的「git 系統」。

git 系統

git 是 kernel 用來維護發展中版本的系統，也就是所謂的「snapshot 」版本，snapshot 版本都是當天新鮮送達的 kernel，釋出時會在後面加上「-git?」字串。

我會不定時點「C」到 kernel 的 git 去看看 kernel 的最新（最近）動態，說不定有我正要找的 patch。git 系統裡也能看到 kernel 的 "commit" 訊息，包含 commit 的作者、時間與差異比較（diff），而且都可以很方便地瀏覽。

結語

隨時與 kernel 的發展同步，有幾個動機：

1. 學習，kernel developers 會討論與多觀念面的議題，很好的學習機會。

2. 新的 kernel 加入了哪些新驅動程式、修正掉哪些臭蟲與增強了哪些驅動程式的功能？

3. 留意我所使用的平臺（architecture）是否有重要的修正（eg. for i386, for ARM...etc）。

4. 如果新 kernel 有加入重要的 feature 或 Bugfix，我會把自己玩耍的 code patch 到新 kernel。

測試這些有趣的新版本，建議使用 QEMU 或是 User-Mode Linux 來進行。

]]> https://www.jollen.org/blog/2006/11/reading_kernel_kernel_patch.html https://www.jollen.org/blog/2006/11/reading_kernel_kernel_patch.html Linux Device Drivers & Kernel Mon, 20 Nov 2006 19:53:07 +0800 出執行檔的 section 與其內容。例如，我想把 ls 命令的 ELF section 列印出來：

# objdump -x /bin/ls |more
...
Idx Name          Size      VMA       LMA       File off  Algn
  0 .interp       00000013  08048114  08048114  00000114  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .note.ABI-tag 00000020  08048128  08048128  00000128  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .hash         0000028c  08048148  08048148  00000148  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .dynsym       000005e0  080483d4  080483d4  000003d4  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .dynstr       000003ea  080489b4  080489b4  000009b4  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .gnu.version  000000bc  08048d9e  08048d9e  00000d9e  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .gnu.version_r 00000070  08048e5c  08048e5c  00000e5c  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .rel.dyn      00000028  08048ecc  08048ecc  00000ecc  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  8 .rel.plt      00000278  08048ef4  08048ef4  00000ef4  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  9 .init         00000017  0804916c  0804916c  0000116c  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 10 .plt          00000500  08049184  08049184  00001184  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 11 .text         0000ab4c  08049690  08049690  00001690  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 12 .fini         0000001b  080541dc  080541dc  0000c1dc  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 13 .rodata       00003760  08054200  08054200  0000c200  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 14 .eh_frame_hdr 0000002c  08057960  08057960  0000f960  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 15 .eh_frame     0000010c  0805798c  0805798c  0000f98c  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 16 .data         00000114  08058000  08058000  00010000  2**5
                  CONTENTS, ALLOC, LOAD, DATA
 17 .dynamic      000000d0  08058114  08058114  00010114  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 18 .ctors        00000008  080581e4  080581e4  000101e4  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 19 .dtors        00000008  080581ec  080581ec  000101ec  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 20 .jcr          00000004  080581f4  080581f4  000101f4  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 21 .got          00000150  080581f8  080581f8  000101f8  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 22 .bss          00000368  08058360  08058360  00010360  2**5
                  ALLOC
...

如果要印出指定 section 的內容，例如 .data section：

# objdump -j .data -s /bin/ls

/bin/ls:     file format elf32-i386

Contents of section .data:
 8058000 00000000 00000000 f0810508 00000000  ................
 8058010 00000000 00000000 00000000 00000000  ................
 8058020 00000080 ffffffff 01000000 01000000  ................
 8058030 00000000 00000000 00000000 00000000  ................
 8058040 02000000 5c420508 01000000 5f420508  ....\B......_B..
 8058050 00000000 00000000 01000000 53720508  ............Sr..
 8058060 01000000 53720508 05000000 61420508  ....Sr......aB..
 8058070 05000000 67420508 02000000 76420508  ....gB......vB..
 8058080 05000000 6d420508 05000000 73420508  ....mB......sB..
 8058090 05000000 73420508 00000000 00000000  ....sB..........
 80580a0 00000000 00000000 05000000 79420508  ............yB..
 80580b0 05000000 6d420508 05000000 7f420508  ....mB.......B..
 80580c0 05000000 85420508 05000000 8b420508  .....B.......B..
 80580d0 05000000 91420508 00000000 97420508  .....B.......B..
 80580e0 a1420508 01000000 ffffffff 01000000  .B..............
 80580f0 90110508 01000000 01000000 00010000  ................
 8058100 a0850508 fc800508 e0750508 01000000  .........u......
 8058110 00000000                           ....

Object file 主要有 3 種類別： 1. relocatable file 2. executable file 3. shared object file relocatable file 即副檔名為 .o 的檔案、executable file 為一般的執行檔、shared object file 則是 *.so（shared libraries）檔案。ELF 是 object file 的檔案格式，其檔案格式如下圖。 圖：ELF View（Execution View v.s. Linking View） Linking view 指的是經由 assembler 或 linkage editor 編譯過，可被 CPU 執行的檔案格式，也就是儲存在儲存裝置上的程式格式（stored programs）。Execution view 指的是由 loader 載入後，程式執行時的格式，也就是存在於記憶體上的程式格式（process）。 當載入器（loader）將程式載入記憶體後，object file 就會是 execution view 的格式。了解 ELF 格式與學會如何讀取 ELF 內容，對於深入研究 Linux 內部的程式實作相當有幫助。例如，未來我們將會討論的 sys_init_module 實作，便需要對「如何讀取 ELF object」有一定程度的了解。 ]]> https://www.jollen.org/blog/2006/11/executable_linking_format_elf_1.html https://www.jollen.org/blog/2006/11/executable_linking_format_elf_1.html GNU Toolchains & Linux Systems Programming Sun, 19 Nov 2006 22:12:09 +0800 來市佔率（使用 Linux 做為 device OS 解決方案的比率）能大幅並快速提升的要素之一：「快速平臺與軟硬解決方案」 （rapid prototyping platform and SW/HW solutions）。 由此可大膽推測，embedded Linux 後期的生態環境正在快速形成當中，或許再過 2~3 年，就會有殺手級的 embedded Linux 的開發工具（IDE）出現。倘若如此，developer 現在一個很重要的工作就是僅快去學習研究 embedded Linux 的基礎原理；未來才能善用工具，而不是只會用工具。 embedded Linux 的開發工具逐漸成形了，會這麼說是因為今天看到一則新聞： 「MontaVista launches Dev Rocket 5 beta」 試想一個情境：怎麼讓「自己寫好的 code」透過 IDE 環境「咚！」一聲就被整合到 target device 的 image 檔（root filesysetm）裡？（像是 TimeSys 的服務，很快，但仍要自己「整」一堆東西到他提供的 RFS 裡。） 推敲一下未來可能的 killer application 身影。 首先引用報導裡關於 Dev Rocket 5 的說明如下：

MontaVista Software has invited current customers to join an open beta program for its next-generation Eclipse-based embedded Linux development toolset.

很好，這是一個 Eclipse-based 的 IDE（如果您不知道 Eclipse 的重要性，網路上有很多前輩發表許多關於他的看法，非常精采）。 根據報導說明，我的想法是，Dev Rocket 能支援「MontaVista Linux Edition Management」，但是如果能把這個地方做成是比較萬用（一般化）的一個 feature，那麼會是比較有彈性而且有殺氣的。要產生 root filesystem image 檔，就要有一個好用的 Linux distribution "build" 工具；目前為特定 target device 建立 Linux distribution 的一套重量級工具是 OpenEmbedded。 OpenEmbedded 是一個舉足輕重的工具，他能方便地建立 embedded Linux distribution。例如之前講到的 Neo1973 Linux mobile phone 就用到 OpenEmbedded。現在好多人在玩的 Linksys NSLU-2 也都是 OpenEmbedded 的產物。 Dev Rocket 5 也支援「One-click Debugging」與「Platform Image Creation and Configuration」的功能；Dev Rocket 5 也有 plug-ins 的功能，能整入像是「UML modeling」這樣的模組進來。 MontaVista 對 embedded Linux 的貢獻良多，未來若是能將這些 IDE open 出來，發散一陣子再收斂起來，這所謂的 killer application 已經不遠了。

Also See

2006.11.08: 「Mobile 2.0 的思考」與第一隻採用 OpenMoko 的 Linux Smartphone - 使用 OpenEmbeded 的 "open" Linux smartphone。 2006.09.22: Embedded Linux 系統性的教學看法 - 提到 OpenEmbedded（使用 bitbake 系統）。

]]> https://www.jollen.org/blog/2006/11/montavista_dev_rock_5_linux_id.html https://www.jollen.org/blog/2006/11/montavista_dev_rock_5_linux_id.html Embedded Linux: Platforms and Applications Thu, 16 Nov 2006 23:08:38 +0800 深入淺出 insmod, #1

作者／陳俊宏
http://www.jollen.org

這篇文章的目的是為了解釋 Linux 驅動程式課程中，經常被詢問的部份，我把這個地方以紅色來標示：

struct file_operations {
	struct module *owner;
	loff_t (*llseek) (struct file *, loff_t, int);
	ssize_t (*read) (struct file *, char *, size_t, loff_t *);
	ssize_t (*write) (struct file *, const char *, size_t, loff_t *);
	int (*readdir) (struct file *, void *, filldir_t);
	unsigned int (*poll) (struct file *, struct poll_table_struct *);
	int (*ioctl) (struct inode *, struct file *, unsigned int, unsigned long);
	int (*mmap) (struct file *, struct vm_area_struct *);
	int (*open) (struct inode *, struct file *);
	int (*flush) (struct file *);
	int (*release) (struct inode *, struct file *);
	int (*fsync) (struct file *, struct dentry *, int datasync);
	int (*fasync) (int, struct file *, int);
	int (*lock) (struct file *, int, struct file_lock *);
	ssize_t (*readv) (struct file *, const struct iovec *, unsigned long, loff_t *);
	ssize_t (*writev) (struct file *, const struct iovec *, unsigned long, loff_t *);
	ssize_t (*sendpage) (struct file *, struct page *, int, size_t, loff_t *, int);
	unsigned long (*get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long);
};

是的，就是 *owner 這個 field 常被問起。*owner 的用途倒底是什麼？（以下以 kernel 2.4.x 為主做說明）

insmod 基本觀念

我用流程的方式來說明。不過在這之前，先請第 128 號系統呼叫 sys_init_module 出場。sys_init_module system call 的主要用途是載入 kernel module，以下是他的原型宣告：

long sys_init_module(const char *name_user, struct module *mod_user);

在這裡我們看到第 2 個參數 *mod_user 就是此行的重點 struct module。另外，sys_init_module 系統呼叫透過 glibc 的 init_module() system call 來叫用。以下是 INIT_MODULE(2)：

NAME
       init_module - initialize a loadable module entry

SYNOPSIS
       #include <linux/module.h>

       int init_module(const char *name, struct module *image);

DESCRIPTION
       init_module loads the relocated module image into kernel space and runs
       the module's init function.

       The module image begins with a module structure and is followed by code
       and data as appropriate.  The module structure is defined as follows:

另外，INIT_MODULE(2) 提到「 This system call is only open to the superuser.」，因此 insmod 只能以 root 身份執行。insmod 的原始碼包含在 modutils 套件裡，insmod 實作呼叫 sys_init_module system call 的程式位於 util/sys_nim.c，函數名稱為 sys_init_module，程式碼內容簡單易懂，節錄如下：

#ifndef CONFIG_USE_SYSCALL

extern int init_module(const char *name, const struct module *info);

int
sys_init_module(const char *name, const struct module *info)
{
  return init_module(name, info);
}

#else

#define __NR_sys_init_module  __NR_init_module
_syscall2(int, sys_init_module, const char *, name,
          const struct module *, info)

#endif

請了解這裡的 sys_init_module 是一個 modutils 自行實作的函數，用來提供給 insmod 指令呼叫，與 kernel 的 sys_init_module system call 是二個不同的東西。insmod 指令的原始碼位於 modutils 套件裡的 insmod/insmod.c，我們已經了解到，insmod.c 會呼叫 util/sys_nim.c:sys_init_module() 來載入 kernel module。

insmod 的程式碼中，載入 kernel module 的工作主要是由 init_module() 來執行，我們透過 init_module() 的原始碼來說明幾件事件：

static int init_module(const char *m_name, struct obj_file *f,
		       unsigned long m_size, const char *blob_name,
		       unsigned int noload, unsigned int flag_load_map)
{
	struct module *module;
	struct obj_section *sec;
	void *image;
	int ret = 0;
	tgt_long m_addr;

	sec = obj_find_section(f, ".this");
	module = (struct module *) sec->contents;
	m_addr = sec->header.sh_addr;

	module->size_of_struct = sizeof(*module);
	module->size = m_size;
	module->flags = flag_autoclean ? NEW_MOD_AUTOCLEAN : 0;

	sec = obj_find_section(f, "__ksymtab");
	if (sec && sec->header.sh_size) {
		module->syms = sec->header.sh_addr;
		module->nsyms = sec->header.sh_size / (2 * tgt_sizeof_char_p);
	}
	if (n_ext_modules_used) {
		sec = obj_find_section(f, ".kmodtab");
		module->deps = sec->header.sh_addr;
		module->ndeps = n_ext_modules_used;
	}
	module->init = obj_symbol_final_value(f, obj_find_symbol(f, "init_module"));
	module->cleanup = obj_symbol_final_value(f,
		obj_find_symbol(f, "cleanup_module"));

	sec = obj_find_section(f, "__ex_table");
	if (sec) {
		module->ex_table_start = sec->header.sh_addr;
		module->ex_table_end = sec->header.sh_addr + sec->header.sh_size;
	}
	sec = obj_find_section(f, ".text.init");
	if (sec) {
		module->runsize = sec->header.sh_addr - m_addr;
	}
	sec = obj_find_section(f, ".data.init");
	if (sec) {
		if (!module->runsize ||
		    module->runsize > sec->header.sh_addr - m_addr)
			module->runsize = sec->header.sh_addr - m_addr;
	}
	sec = obj_find_section(f, ARCHDATA_SEC_NAME);
	if (sec && sec->header.sh_size) {
		module->archdata_start = sec->header.sh_addr;
		module->archdata_end = module->archdata_start + sec->header.sh_size;
	}
	sec = obj_find_section(f, KALLSYMS_SEC_NAME);
	if (sec && sec->header.sh_size) {
		module->kallsyms_start = sec->header.sh_addr;
		module->kallsyms_end = module->kallsyms_start + sec->header.sh_size;
	}
	if (!arch_init_module(f, module))
		return 0;

	/*
	 * Whew!  All of the initialization is complete.
	 * Collect the final module image and give it to the kernel.
	 */
	image = xmalloc(m_size);
	obj_create_image(f, image);

	if (flag_load_map)
		print_load_map(f);

	if (blob_name) {
		int fd, l;
		fd = open(blob_name, O_WRONLY|O_CREAT|O_TRUNC, S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH);
		if (fd < 0) {
			error("open %s failed %m", blob_name);
			ret = -1;
		}
		else {
			if ((l = write(fd, image, m_size)) != m_size) {
				error("write %s failed %m", blob_name);
				ret = -1;
			}
			close(fd);
		}
	}

	if (ret == 0 && !noload) {
		fflush(stdout);		/* Flush any debugging output */
		ret = sys_init_module(m_name, (struct module *) image);
		if (ret) {
			error("init_module: %m");
			lprintf("Hint: insmod errors can be caused by incorrect module parameters, "
				"including invalid IO or IRQ parameters.\n"
			        "      You may find more information in syslog or the output from dmesg");
		}
	}

	free(image);

	return ret == 0;
}

重要的觀念如下：

1. struct module 是「module descriptor」，kernel 的 module manager 以 module descriptor 來維護 kernel module。我們把 struct module 稱為 module object。

2. 看藍色的部份，運算子的左邊。init_module() 負責「setup module object」。

3. 看紅色的部份，module object 的內容主要是讀取自 kernel module object file 裡的特定 section。

4. 最後是綠色的部份，讀完 object file 裡的特定 section，並 setup 好 module object 後，就呼叫 sys_init_moddule() 來載入 module object 至 kernel-space。

了解主要的觀念與流程後，再來就是重要的小結了！

insmod 整體觀念

insmod 指令使用 sys_init_module 系統服務，將  kernel module 載入到 kernel 的 address space。例如，載入 hello.o 的命令為：

# insmod hello.o

要了解 kernel module 的載入過程，必須由 insmod 的原始碼開始討論。 這裡只是一開始，所以沒有對程式碼的細節做太多介紹，當然這是後面才需要做的功課。

關於 *owner 的小結

透過以上的說明，我們就可以來回答「*owner 的用途倒底是什麼？」的問題了。

*owner 的 data type 是 struct module，即 module object 的資料結構。在整個 kernel module 的載入過程中，module object 是由 insmod 指令所設置，並且是代表 kernel module object file。

所以，*owner 是 kernel module 的觀念，與「Linux 驅動程式」沒有關係。fops 才是Linux 驅動程式的觀念。

最後，為什麼 fops 裡要有 *owner 呢？答案就很明顯了：Linux 驅動以 fops->owner 來表示「我這個驅動程式是屬於（is owned）那一個 kernel module」。

關於更多 *owner，我們可以想到的是，驅動程式的 usage count 是紀錄在 module object 裡，而不是 file operation（思考為什麼），所以當我們對 usage count 做 increment/decrement 時，就需要 module object。

另外，關於寫 Linux 驅動程式時，「要不要管 *owner」的答案也是很清楚了，基本上，我們可以先不用理會這個 field，但是如果要給 *owner 欄位值的話，根據 Linux kernel 的說明，我們只要這麼寫即可：

static struct file_operations xxx_ops = {
	owner:		THIS_MODULE,
	...
};

THIS_MODULE 的定義是（include/linux/module.h）：

#define THIS_MODULE (&__this_module)

__this_module 是一個外部符號，用來表示「這個驅動程式所屬的 module object」。如果是分層的驅動程式，那麼這個 field 就要填。

課堂上我們再以 busmouse.c / logibusmouse.c 來說明這個部份。

Also See

2006.10.07: Linux 2.4.29 System Calls Table (LSCT)

　

]]> https://www.jollen.org/blog/2006/11/hello_world_insmod_1.html https://www.jollen.org/blog/2006/11/hello_world_insmod_1.html Linux Device Drivers & Kernel Wed, 15 Nov 2006 20:52:32 +0800 Is Java's move to GPL too late?」的討論。在這 10 幾年的精采發展過程中，Java 也曾回拒 open source 的想法與建議，最終仍然無法抵擋一個潮流與趨勢。 與其說 Sun 是在無計可施的局面下選擇 open source，我覺得還不如說這是 open source 這個「生態環境（ecosystem）」的成形、成熟與狀大，讓人「不可不為」。當然這是我自己的看法。 對 open source 生態系統最早「覺醒」，並且也因為認可這個 ecosystem 而得好處的經典案例就是「IBM」了，而今年也能嗅到 Linux mobile phone 生態環境的成形，想必未來 2 年 Linux mobile phone 是大有可為的。因此，假如 Sun 不想在 Linux mobile phone 的歷史缺席，就算不解或無奈，也只能聰明的加入已成形的生態系統裡。 IBM 擁有許多作業系統的專利，透過智財保護，並進行授權或 royalty 似乎是天經地義的做法，但是這位老大哥選擇並且認真加入 open source 生態環境的運作，最後得到許多好處與回饋，也讓人見識到 ecosystem 讓人不可不為的威力。IBM 的 PowerPC 也選擇了 open source community 的系統，只不過 IBM 比 Sun Microsystems 更有智慧，我想這是未來將會被更熱烈討論的主題（ecosystem of open source community）。 把這個好消息看待得太嚴肅了，對 developer 來說，又多了一項新奇有趣的東西，值得期待！ 以下是這則新聞的主要閱讀列表： Sun GPLs Java, http://www.linux-watch.com/news/NS4348361333.html. Sun GPLs Java, targets mobile phones, http://www.linuxdevices.com/news/NS6857451192.html.]]> https://www.jollen.org/blog/2006/11/sun_microsystem_gplv2_java_1.html https://www.jollen.org/blog/2006/11/sun_microsystem_gplv2_java_1.html Embedded Linux: Platforms and Applications Tue, 14 Nov 2006 21:07:05 +0800 LinuxWatch 的報導中提出 1.2 版是一個重要的里程碑，節錄原始報導如下：

Mono 1.2 enables Linux and Unix users to use Microsoft .NET code and applications. This new version, which brings performance improvements and support for Windows Forms, is seen as an important milestone toward compatibility with the .NET Framework 2.0. Other enhancements in the latest release include virtual machine upgrades, enhanced Java support, better memory consumption, stability improvements, and support for more .NET 2.0 features.

Mono 1.2 的新突破是可以讓 Microsoft 的 UI（user interface）更容易轉移到 Linux 平臺上。Mono Project 的官方網站是：http://www.mono-project.com/Main_Page，現在已經可以下載到 Mono 1.2 了。 對 Linux 應用軟體開發的朋友，可以了解一下這個重要的專案計畫。]]> https://www.jollen.org/blog/2006/11/novell_mono_12linux_net.html https://www.jollen.org/blog/2006/11/novell_mono_12linux_net.html Embedded Linux: Platforms and Applications Mon, 13 Nov 2006 00:04:52 +0800 ogg 與 MP3 二種格式可取得。 找個時間一定要仔細聽聽這個訪談，畢竟 GPLv3 很可能會決定開放源碼解決方案的大未來。 ]]> https://www.jollen.org/blog/2006/11/linux_link_tech_show_gplv3.html https://www.jollen.org/blog/2006/11/linux_link_tech_show_gplv3.html 其它 Sun, 12 Nov 2006 23:43:59 +0800 我們知道，在 start_kernel() 的開機過程中，會呼叫許多初始化核心的常式。其中 fork_init() 是用來初始化 kernel 的"fork" 環境的。"fork()" 是用來產生 child process 的 system call，當 parent process 想要執行外部程式時，會先 fork child process，接著 child process 再利用 exec system call 自己的空間取代為外部程式。


從講義第 5 頁開始，我們把問題做分割，找出與 Scheduling 有關的初始化流程來做研讀，因為我們想要以 Scheduling 做為深入 Linux kernel 的第一門課。

講解 fork_init()

1. Kernel 能 fork 的 process 數是依據 physical memory 的大小來決定的，我們看到 fork_init(unsigned long mempages) 的 mempages 即是用來計算 max_threads 的參數。

2. 看到 mempages 參數，這個參數是由 start_kernel() 呼叫 fork_init() 時傳入的：

asmlinkage void __init start_kernel(void)
{
   ...
   fork_init(num_physpages);
   ...
}

3. 找一下 num_physpages，原來是 kernel 的 global symbol 啊，這個地方在 mm/memory.c：

unsigned long num_physpages;
...
EXPORT_SYMBOL(num_physpages);

我們的想法是，目前還沒讀到有關 Memory Manager 與 mm 初始化的主題，所以還不如先暫時把這個地方當黑盒子，再做一次分割。因此，num_physpages 是怎麼來的就先放到「TODO」清單裡了。

4. 計算 max_threads 需要以下二個常數：

a. THREAD_SIZE：dependent on architecture

b. PAGE_SIZE：dependent on architecture

這二個常數都是平臺相依的，我把他們都標示在投影片上。這是在 processor-level 的 porting 就要處理掉的。

5. 再來，如同程式碼所述：至少要能產生 20 個 thread 系統才能開機。所以限定 max_threads 的最小值是 20。

另外，我們會發現有些與 "memory" 或 "signal" 有關的 code，目前比較好的做法是先放到「TODO」。希望我們這裡的思考邏輯與陳述方式對大家「閱讀核心」能有一點幫助。

跟上我們的腳步：請先行閱讀以下的文章，再看這篇日記！

2006.10.22: Jollen 的 Linux 核心分享包,#1: 《開工篇》 2006.10.24: Jollen 的 Linux 核心分享包,#2: 《講義1~5》

]]> https://www.jollen.org/blog/2006/11/jollen_linux_3_fork_init.html https://www.jollen.org/blog/2006/11/jollen_linux_3_fork_init.html Linux Device Drivers & Kernel Thu, 09 Nov 2006 23:41:50 +0800 這隻手機是由台灣的大眾電腦所開發（真是一個好消息），原始的報導在 LinuxDevices.com 上，詳情可點閱這篇文章「Cheap, hackable Linux smartphone due soon」。

Neo1973（代號：FIC-GTA001） 是「completely open, Linux-based, GPS-equipped, quad-band GSM/GPRS phone」，沒錯，這是一隻「PHS 手機」。預計上市的時間是今年（2006）的 12 月中，並在明年的 1 月份銷售。

Neo1973 採用 Samsung S3C2410 平臺，並且是第一隻採用「OpenMoko」平臺的 Linux 智慧型手機，此外，更採用「apt-get-lke」的 software manager。不管正著看還是反著看，都很符合 Linux 玩家的習慣（與期望）。

非常期待他的問世，到時一定要去帶一隻回家「hack hack」一番。

Sean Moss-Pultz（Neo1973 的 PM，大眾電腦），在 Amsterdam（阿姆斯特丹）所舉行的「Open Source in Mobile」 conference 上發表了一篇演說，內容是有關於「OpenMoKo」這個 Linux smartphone 專用的 application framework 與即將推出的 Neo1973 Linux 智慧型手機。這篇演說的後半段提到一個 Linux 智慧型手機的 ecosystem（生態）觀念，他稱之為「Mobile 2.0」。 這場演講提出一個讓人充滿無限想像空間的「Mobile 2.0」概念，假使以使用者與互動為主的 WWW 是 Web 2.0，那麼將來以使用者與互動為主的 mobile phone 不就是「Mobile 2.0」。 如果 Linux 是自由開放的國度，使用者是 Mobile 2.0 的核心價值，那麼未來 Linux Smartphone 哪需要與微軟較勁？ 最近這一年，可以陸續看到許多 Linux 智慧型手機出場在大眾市場，而當大家只看到 Linux 智慧型手機聲斯力竭地與微軟較勁時，Mobile 2.0 的觀點著實另人興奮。

突然發現到，我好像已經加入 Moss-Pultz 的 ecosystem 一員了，顯然我是這個系統的 end user。這個互動來自於「open hacking」的思維邏輯，近年來似乎被不少的國際大廠巧妙地應用著。（突然一個唸頭閃過，昨天參加的一場 roadshow 不就也是如此！）

　

（圖片來源：http://www.linuxdevices.com/news/NS2986976174.html）

Neo1973 其實是採取「dual-OS」的產品策略，因此她也能執行 Microsoft Windows Mobile。不過大家最期待的「Open Source」節錄一小段原始報導的說明如下：

Because OpenMoKo consists exclusively of open-source software, the Neo1973 will ship with a limited feature set, including a dialer (image at left), unified SyncML-enabled email/text messaging client, phonebook, (image at right), and media player, according to Moss-Pultz. However, many additional open source applications will be available through "feeds," including "certified" ones from FIC, as well as those from commercial and community sources, he adds.

還有更棒，Neo1973 採用 OpenEmbedded 來讓使用者增加、移除與更新套件，OpenEmbedded 裡頭已經包含了數以「千」計的套件，透過 bitbake 來建立 Linux distribution，讓愛好者與玩家都能透過簡單的指令來實做「Embedded Linux to Devices」。

Neo1973 的 hardware 規格也是很棒的，整理如下：

1. Samsung S3C2410 SoC

2. 128MB RAM

3. 64M flash

4. 64MB MicroSD

5. 2.8" touchscreen

6. Assisted GPS

7. quad-band GSM/GPRS module

Moss-Pultz 的 presentation 可以在這裡找到：http://www.linuxdevices.com/files/article072/sld002.html

OpenMoko 的「official site」是：http://www.openmoko.com/press/index.html。在這上面有完整的新聞稿與簡報 PDF 檔可以下載。

Revision, 2006/11/09, 01:13PM.]]> https://www.jollen.org/blog/2006/11/mobile_20_openmoko_linux_smart.html https://www.jollen.org/blog/2006/11/mobile_20_openmoko_linux_smart.html Embedded Linux: Platforms and Applications Wed, 08 Nov 2006 20:37:08 +0800 「作業系統的排程器（scheduler）提供好幾種排程演算法，並在不同的應用場合，或是不同的 process 採取適合的排程策略（policy）。」

Linux 的 process descriptor 資料結構為 struct task_struct，我們最早開始談論與 process 有關的 system call 時，就看過這個用來描述 process 的資料結構。struct task_struct 裡頭的 policy 欄位便是用來描述該 process 的排程策略。

與排程有關的系統呼叫

整理與 scheduling 有關的幾個 system call 如下（可參考「Linux 2.6 的 System Call：12 大類」），另外 Jollen 也把到目前為止已介紹過的 system call 加上紅色註記。

號碼	System Call 名稱	Manipulation
34	sys_nice	關於 struct task_struct->nice 欄位。
154	sys_sched_setparam	關於 struct task_struct->rt_priority 欄位。
155	sys_sched_getparam	關於 struct task_struct->rt_priority 欄位。
156	sys_sched_setscheduler	關於 struct task_struct->policy 欄位。（這是下一個要讀的）
157	sys_sched_getscheduler	關於 struct task_struct->policy 欄位。
158	sys_sched_yield	暫不討論。
159	sys_sched_get_priority_max	根據 'policy' 傳回 'rt_priority' 所允許的最大 priority 值。
160	sys_sched_get_priority_min	根據 'policy' 傳回 'rt_priority' 所允許的最小 priority 值。
161	sys_sched_rr_get_interval	若 policy 為 SCHED_RR（Round Robin policy），則傳回 time quantum（time slice）值。
241	sys_sched_setaffinity	這是 Linux 2.6 新增加的 system call。
242	sys_sched_getaffinity	這是 Linux 2.6 新增加的 system call。

「'sys_sched_getscheduler' 便是用來取得 process 排程策略（policy）的 system call。」

「'struct task_struct->policy' 是今天要了解的主題。」

我們想要思考一個問題「作業系統的教科書提到的排程演算法中，Round Robin 是我們知道現在的分時作業系統（eg. Linux）所採用的策略，所以我想了解 Linux 的 process descriptor 裡，是哪一個 field 在紀錄這件事情。」

struct task_struct 的 policy 欄位

這個問題還挺簡單的，因為直接看 struct task_struct 幾乎就能猜到是哪一個 field，再用谷歌找資料來印證我們的設假；另外，看「Understanding the Linux Kernel」也寫的很清楚。

struct task_struct {
	...
	unsigned long policy;
	...
};

接著再回頭來看今天的主題，sys_sched_getscheduler 的實作（Linux 2.6.11+）：

/**
 * sys_sched_getscheduler - get the policy (scheduling class) of a thread
 * @pid: the pid in question.
 */
asmlinkage long sys_sched_getscheduler(pid_t pid)
{
	int retval = -EINVAL;
	task_t *p;  // jollen: 'typedef struct task_struct task_t;'

	if (pid < 0)
		goto out_nounlock;

	retval = -ESRCH;
	read_lock(&tasklist_lock);
	p = find_process_by_pid(pid); // 參照說明 1.
	if (p) {
		retval = security_task_getscheduler(p);
		if (!retval)
			retval = p->policy; // 參照說明 2.
	}
	read_unlock(&tasklist_lock);

out_nounlock:
	return retval;
}

取出重點部位來看：

1. 取得指定 PID 的 process descriptor。常常在一些說明文件看到「若 PID 為 0，則取得 current 的...」，不過這裡的實作好像看的不太清楚，沒關係等一下再來往下看 code。
2. 傳回 policy 欄位。

很簡單的將 sys_sched_getscheduler 看了一下，並且了解到 policy 欄位的用途。

find_process_by_pid

把 find_process_by_pid() 的實作拿出來看：

/**
 * find_process_by_pid - find a process with a matching PID value.
 * @pid: the pid in question.
 */
static inline task_t *find_process_by_pid(pid_t pid)
{
	return pid ? find_task_by_pid(pid) : current;
}

發現一件很重要的是，也是之前都沒提過的。

「若 PID 為 0，則傳回 current，否則傳回 PID 為 pid 的 process 之 process descriptor。」

別忘了，current 的 data type 也是 'struct task_struct'。

Linux 排程策略：policy 欄位的值

Linux 2.6 提供的排程策略如下：

/*
 * Scheduling policies
 */
#define SCHED_NORMAL		0
#define SCHED_FIFO			1
#define SCHED_RR			2
#define SCHED_BATCH		3

定義在 include/linux/sched.h。順帶把 Linux 2.4 提供的排程策略也節錄一下：

/*
 * Scheduling policies
 */
#define SCHED_OTHER		0
#define SCHED_FIFO			1
#define SCHED_RR			2

]]> https://www.jollen.org/blog/2006/11/linux_system_calls_forum_7157s.html https://www.jollen.org/blog/2006/11/linux_system_calls_forum_7157s.html Linux Device Drivers & Kernel Sun, 05 Nov 2006 00:03:08 +0800 「Linux System Calls' Forum」與「Jollen 的 Linux 核心分享包」是二個相互配合的專欄，因此相關的日記彼此之間是具備相依性與次序的。建議的閱讀順序是「依照日記的時間（即發佈順序）」來閱讀「Linux System Calls' Forum」與「Jollen 的 Linux 核心分享包」。這是這二個系統日記的閱讀建議。

目前的狀況報告

對於 Linux system call 的討論，我們已經來到了 scheduler 的門口了，要深入了解 Linux scheduler 的設計原理與相關理論前，Jollen 還必須多做一點功課才行。到目前為止，我們所討論過的幾個 system call 如下。

跟上我們的腳步：請讀以下的文章，再看這篇日記！

2006.10.11: Linux System Calls' Forum, #1：(第20號系統服務) sys_getpid 2006.10.12: Linux System Calls' Forum, #2：(第199,201,200,202,224號系統服務) sys_getuid, sys_geteuid, sys_getgid, sys_getegid, sys_gettid 2006.10.14: Linux System Calls' Forum, #3：(第64號系統服務) sys_getppid 2006.10.15: Linux System Calls' Forum, #4：(第34號系統服務) sys_nice 2006.10.19: Linux System Calls' Forum, #5：(第96號系統服務) sys_getpriority 2006.10.20: Linux System Calls' Forum, #6：(第97號系統服務) sys_setpriority

「Jollen 的 Linux 核心分享包」已發佈二則日記如下。

跟上我們的腳步：請讀以下的文章，再看這篇日記！

2006.10.22: Jollen 的 Linux 核心分享包,#1: 《開工篇》 2006.10.24: Jollen 的 Linux 核心分享包,#2: 《講義1~5》

另外，Jollen 在每一個 system call 的討論都點出幾個基本的主題，希望大家能大致了解這目前「Linux System Calls' Forum」裡出現的幾個主題後，再繼續往下看「Linux System Calls' Forum」論壇。

後續進度

這篇日記完成後，緊接著的就是「Linux System Calls' Forum, #7：（第157號系統服務）sys_sched_getscheduler」，後然緊接的是「Jollen 的 Linux 核心分享包,#3」了，請大家多多指正！

]]> https://www.jollen.org/blog/2006/11/linux_system_calls_forumjollen.html https://www.jollen.org/blog/2006/11/linux_system_calls_forumjollen.html Linux Device Drivers & Kernel Sat, 04 Nov 2006 21:34:02 +0800 之前提到過 Kernel 2.6 的 KVM 驅動程式現身了，今天看到 KVM 驅動程式的 HOWTO 已經上線了。KVM 的官方網站是：http://kvm.sourceforge.net/ 裡頭除了有 HOWTO 外，也有 mailing list 可以加入了。KVM 的驅動程式除了有 kernel-space 的 driver 外，也包含一個 user-space 的 library，以及給 QEMU 的 patch。]]> https://www.jollen.org/blog/2006/11/kvm_howto.html https://www.jollen.org/blog/2006/11/kvm_howto.html Linux Device Drivers & Kernel Thu, 02 Nov 2006 22:03:10 +0800 sys_getppid 時，跳掉了一段 code 如下：

#if defined(CONFIG_SMP) || defined(CONFIG_PREEMPT)
{
   ...
}
#endif

這段 code 在判斷 kernel 是否有 'CONFIG_SMP'（多處理器）與 'CONFIG_PREEMPT'（可搶先的 process 排程）。目前 kernel 2.6 在各種處理器平臺已經支援 preemptive process scheduler，當然也包含了 i386 處理器。 這個 kernel 的設定位於 arch/i386/Kconfig，我們節錄 Kconfig 內容如下：

config PREEMPT
        bool "Preemptible Kernel"
        help
          This option reduces the latency of the kernel when reacting to
          real-time or interactive events by allowing a low priority process to
          be preempted even if it is in kernel mode executing a system call.
          This allows applications to run more reliably even when the system is
          under load.

          Say Y here if you are building a kernel for a desktop, embedded
          or real-time system.  Say N if you are unsure.

這段 code 與 CONFIG_PREEMPT 的用意非常清楚：提供 preemptive process scheduling 的能力，我們對 Linux kernel preemptive process scheduling 的處理方法相當感興趣。 在進一步研究與 scheduling 有關的 system call 與 'CONFIG_PREEMPT' 前，有必要先來複習一下什麼是 "preemptvie"。 Preemption 一個重要的工作是了解「preemptive」的觀念。 當 process 進入執行狀態（running state）時，排程器（scheduler）會去檢查進入該 process 優先序（priority），若該 process 的 priority 比目前執行中的 process priority 高，Linux 便會搶先（preemptive）執行該 process，因此原本的 process 便被中斷（interrupt）。 這種 high priority process 把 low priority process 執行權了活生生搶走的機制便是 preemptive process scheduling；因此我們說，Linux 的 process 是 "preemptive"！Preemption（搶奪）的排程，目前在 Linux 2.6 的核心裡已經有不錯的支援了。 更多 Linux Preemptive Scheduling 1. Linux 的 scheduler 包含 preemptive 的實作。 2. Linux kernel 本身是 nonpreemptvie。我們在這裡指的 "preemptive" 是指 "process preemptive"。所以當 process 是在 User Mode 時才能被搶先。 3. Process preemptvie（可被搶先因此中斷）：process 除了在 time-slice 用完時被中斷外（典型案例），在某些狀況下也是可以被中斷的。例如，前面提到的優先序問題便是一例。 4. 被中斷的 process 仍然是 running state（因為只是被搶先而已）。 Linux/Unix 作業系統核心是 nonpreemptive 的實作，這樣的作業系統設計較簡單，並且可免除許多核心同步（kernel synchronization）的問題。 Preemptive Scheduling 以下是節錄自作業系統教科書裡，對於可搶先班程的說明[1]：

CPU scheduling decisions may take place when a process - 1. Switches from running to waiting state. 2. Switches from running to ready state. 3. Switches from waiting to ready. 4. Terminates. Scheduling under 1 and 4 is nonpreemptive.

這裡有一份 preemption 的名詞解釋：http://www.netrino.com/Publications/Glossary/Preemption.html [1] A. Silberschatz, P. Galvin, and G. Gagne, Applied Operating System Concepts, First Edition, John Wiley & Sons, Inc. (2000).]]> https://www.jollen.org/blog/2006/11/_scheduler_running_process.html https://www.jollen.org/blog/2006/11/_scheduler_running_process.html Linux Device Drivers & Kernel Thu, 02 Nov 2006 14:55:15 +0800 Ragel 是一個 "State Machine Compiler"，Ragel 可以把狀態機（regular expression）編譯成 C/C++/Objective-C/D 程式碼。Ragel 除了可以用來快速撰寫分析文件的程式外，用來學習 Automata 也是很好的工具。 Ragel 的官方網站：http://www.cs.queensu.ca/~thurston/ragel/ https://www.jollen.org/blog/2006/11/ragel.html https://www.jollen.org/blog/2006/11/ragel.html 其它 Wed, 01 Nov 2006 20:48:08 +0800 FreeDOS 在今年 9 月時釋出了重大的里程（big milestone）版本 "1.0"。FreeDOS 是一個 "complete", "free", "100% MS-DOS compatible" 的 operating system，今天心血來潮，把她裝起來玩了一下，其實還真有點懷念呢。 懷念的滋味：西冒號斜線大於。 DOOM！]]> https://www.jollen.org/blog/2006/11/_freedos_10.html https://www.jollen.org/blog/2006/11/_freedos_10.html 其它 Wed, 01 Nov 2006 12:41:55 +0800 # ./configure --enable-unicode=ucs4 --prefix=/usr 2. 安裝 Psyco（Python JIT Compiler）：這是必要的，以快加 bitbake 建立套件的速度。我們測試的版本是 2006/10/23 的 snapshot，實測後可順利運作，不過更新一點的 snapshot 我想應該也不致於有太大問題。 3. 安裝 text2html library，我們實測的版本是 texi2html 1.64。 4. 安裝 xmlto，我們使用的版本是 xmlto 0.0.18。 以下是 bitbake 1.6 在我們的 Red Hat Linux 9 下運作的畫面。 ]]> https://www.jollen.org/blog/2006/10/_red_hat_linux_9_bitbake_16.html https://www.jollen.org/blog/2006/10/_red_hat_linux_9_bitbake_16.html 其它 Tue, 31 Oct 2006 23:43:55 +0800 基本上這是一個 computation platform，因此需要軟體「分散式計算技術」的支援。不過不拿這個可怕的題目來討論，基本上 Linux 要有一個無硬碟的計算環境，最簡單的方法是「NFS」。 (一台機器可安插 4 片 diskless server board，可做為小型的伺服器或計算平臺。) NFS 果然是萬用解決方案，像是這種異質性平臺（host v.s. target、client v.s. server），利用 NFS 來掛載（mount）host（或server）端的 Linux distribution 到 target（或 client）端來做計算，是最簡單的方法。 唯一需要具備的能力是： 1. NFS 的設定：/etc/exports。 2. 製作 target 的 NFS bootstrap root filesystem。 3. 灌一套支援 target 端的 Linux distribution 在 host 端。 以下是這個「server board」的 block diagram。 diskless-blade server 的幾個好處是： 1. 資料存放於 remote data server。 2. 將計算（computation）與資料儲存（storage）分開：separate computation from storage。 3. 計算端（computation）的損壞不影響資料安全性。 4. 提供較佳的備援。 5. 使用 Giga lan 互連（connectivity），佈署成本（deployment）較低（see the block diagram）。 至於軟體端的解決方案，我想大家應該也都猜得到，這片伺服器板是使用 U-Boot + Linux 2.6.x 做為解決方案。

Also See

PowerPC 衝吧！：關於 PowerPC 的 NFS root filesystem。

]]> https://www.jollen.org/blog/2006/10/ibm_powerpc_1.html https://www.jollen.org/blog/2006/10/ibm_powerpc_1.html Embedded Linux: Platforms and Applications Tue, 31 Oct 2006 13:29:28 +0800 *2。 -mregparm 用來指定有多少個 integer 的參數可以透過暫存器（register）來傳遞， 以下是 -mregparm 的 man（GCC(1))：

Intel 386 and AMD x86-64 Options
...
-mregparam
           Use a different function-calling convention where the first two
           arguments are passed in registers.

kernel 的編譯設定中（menuconfig），也提供一個選項來設定「暫存器參數的傳遞」。這個設定位於 menuconfig 的 「Processor type and features|Use register arguments (EXPERIMENTAL) (NEW)」，Jollen 所使用的 kernel 版本是 Linux v2.6.11 (for i386)，如果您的 kernel 不是 i386 或是版本不同，您可能無法在這個地方找到此設定項。 Kconfig 與 -mregparam 以下是節錄自 arch/i386/Kconfig 的內容：

config REGPARM
        bool "Use register arguments (EXPERIMENTAL)"
        depends on EXPERIMENTAL
        default n
        help
        Compile the kernel with -mregparm=3. This uses a different ABI
        and passes the first three arguments of a function call in registers.
        This will probably break binary only modules.

        This feature is only enabled for gcc-3.0 and later - earlier compilers
        generate incorrect output with certain kernel constructs when
        -mregparm=3 is used.

當我們把 REGPARM 設定為 'y' 後，Makefile 裡的 CONFIG_REGPARM 值也會是 'y'。當 CONFIG_REGPARM=y 時，cflags-y 便加 "-mregparm=3" 的參數，請注意 Kernel 2.6.x 必須以 3.2.x 以上的 gcc 來編譯^*1。相關的 Makefile 節錄如下（arch/i386/Makefile）：

# -mregparm=3 works ok on gcc-3.0 and later
#
GCC_VERSION                     := $(call cc-version)
cflags-$(CONFIG_REGPARM)        += $(shell if [ $(GCC_VERSION) -ge 0300 ] ; then echo "-mregparm=3"; fi ;)

# Disable unit-at-a-time mode, it makes gcc use a lot more stack
# due to the lack of sharing of stacklots.
CFLAGS += $(call cc-option,-fno-unit-at-a-time)

CFLAGS += $(cflags-y)

最後，CFLAGS 的值會加上 '$(cflgs-y)'，我們知道 CFLAGS 是 gcc 的編譯參數設定變數，所以當 gcc 在編譯 kernel 時，便會套用 "-mregparm=3" 的參數。

Also See

Jollen 的 Linux 核心分享包,#2: 《講義1~5》*1 關於 gcc 的 __attribute__ 用法*2

]]> https://www.jollen.org/blog/2006/10/kconfig_mregparmnum.html https://www.jollen.org/blog/2006/10/kconfig_mregparmnum.html GNU Toolchains & Linux Systems Programming Mon, 30 Oct 2006 15:27:43 +0800 __attribute__ 標籤。__attribute__ 用來讓我們定義函數的行為，以便告訴 gcc 在編譯時期對此函數做一些特殊的處理或檢查動作。 以 asmlinkage 的例子來說，asmlinkage 的定義是（/usr/include/linux/linkage.h）：

#if defined __i386__
#define asmlinkage CPP_ASMLINKAGE __attribute__((regparm(0)))
#elif defined __ia64__
#define asmlinkage CPP_ASMLINKAGE __attribute__((syscall_linkage))
#else
#define asmlinkage CPP_ASMLINKAGE
#endif

由此可知，以 sys_nice() 的原型宣告來說，以下的二行程式碼是等價的：

asmlinkage sys_nice(...);
__attribute__((regparm(0))) sys_nice();

"__attribute__" 寫在函數宣告之前或之後都可以（左括號前或右括號後），並接著使用一對「雙括號」來註明此函數的屬性。語法：

__attribute__((keywords)) functon_name(...);

屬性的關鍵字如下（節錄自 gcc 3.4.6 manual）：

noreturn,noinline, always_inline, pure, const, nothrow, format, format_arg, no_instrument_function, section, constructor, destructor, used, unused, deprecated, weak, malloc,alias, warn_unused_result, nonnull.

regparm 的用法與用途 regparm 的語法是：regparm(number)，regparm 屬性只在 Intel 386 平臺上有作用，用來指定最多可以有多少個（"number" ）參數（arguments）能以暫存器來傳遞，regparm(0) 表示參數都不能透過暫存器來傳遞，因此所有參數都會透過堆疊來傳遞。 更多關於__attribute__ 又如，在 ARM 平臺上宣告 "__attribute((interrupt))" 表示此函數是一個 interrupt handler。 其它的屬性說明可參閱 gcc 的手冊。 __attribute__ 是重要的 gcc 用法，對系統程式（system software）的開發尤其重要，應仔細閱讀 gcc 手冊。

Also See

什麼是 "asmlinkage"？

]]> https://www.jollen.org/blog/2006/10/_gcc___attribute.html https://www.jollen.org/blog/2006/10/_gcc___attribute.html GNU Toolchains & Linux Systems Programming Fri, 27 Oct 2006 00:02:15 +0800 asmlinkage long sys_nice(int increment) "asmlinkage" 是在 i386 system call 實作中相當重要的一個 gcc 標籤（tag）。 當 system call handler 要呼叫相對應的 system call routine 時，便將一般用途暫存器的值 push 到 stack 裡，因此 system call routine 就要由 stack 來讀取 system call handler 傳遞的參數。這就是 asmlinkage 標籤的用意。 system call handler 是 assembly code，system call routine（例如：sys_nice）是 C code，當 assembly code 呼叫 C function，並且是以 stack 方式傳參數（parameter）時，在 C function 的 prototype 前面就要加上 "asmlinkage"。 加上 "asmlinkage" 後，C function 就會由 stack 取參數，而不是從 register 取參數（可能發生在程式碼最佳化後）。 更進一步的說明... 80x86 的 assembly 有 2 種傳遞參數的方法： 1. register method 2. stack method Register method 大多使用一般用途（general-purpose）暫存器來傳遞參數，這種方法的好處是簡單且快速。另外一種傳遞參數的做法是使用 stack（堆疊），assembly code 的模式如下： push number1 push number2 push number3 call sum 在 'sum' procedure 裡取值的方法，最簡單的做法是： pop ax pop ax pop bx pop cx Stack Top 是放 IP，我們傳給 sum procedure 的參數由 stack 的後一個 entry 開始讀取。 其它有關 asmlinkage 1. asmlinkage 是一個定義 2. "asmlinkage" 被定義在 /usr/include/linux/linkage.h 3. 如果您看了 linkage.h，會發現 "__attribute__" 這個語法，這是 gcc 用來定義 function attribute 的語法。]]> https://www.jollen.org/blog/2006/10/_asmlinkage.html https://www.jollen.org/blog/2006/10/_asmlinkage.html Linux Device Drivers & Kernel Thu, 26 Oct 2006 16:15:38 +0800 http://forum.jollen.org/index.php?showtopic=6899]]> https://www.jollen.org/blog/2006/10/kernel_26_battery_class.html https://www.jollen.org/blog/2006/10/kernel_26_battery_class.html Linux Device Drivers & Kernel Wed, 25 Oct 2006 10:35:36 +0800

講義第1頁到第5頁的說明。

課前說明

作業系統（operating system）理論的教材書，與 process 和 scheduling（排程）相關的主題都是最先被討論的議題。因此，對於 Linux kernel 原始碼的研究，我們也從 process 與 scheduling 有關的部份開始講起。



Process 是執行中的程式，因此「程式如何被執行」是第一個重點，這個部份的觀念當然也包含「程式如何由儲存裝置載入」。緊接著的是，「程式載入記憶體後的佈局（layout）」，這是第二個要研究的重點。當程式被載到記憶體後，作業系統的 scheduler（排程器）便負責排程的工作與執行本文切換（context switch），這是第三個所要討論的重點。

因此，我們將會研究 Linux kernel 的 3 個「process and scheduling」議題：

1. Shell 如何載入執行檔（ELF executables）至記憶體。
2. Process 的 memory 資枓結構。
3. Linux scheduling 與 x86 context switch。

在開始進入主題前，我們先來了解一下 Linux kernel 的開機流程與 scheduler 初始化的關係。然後我們會接著討論「Process Creation」，並一併說明「 Shell 如何載入執行檔（ELF executables）至記憶體」。

編譯 Kernel 2.6 的注意事項


Kernel 2.6 的編譯必須使用 gcc 3.2 版以上，這張講義的 code 位於 init/main.c，由這段 code 也能知道，在編譯時期（compile time）就會做 gcc 版本的檢查。

Operating System Entry Point

init/main.c:start_kernel() 是「 architecture-independent booting process」的起點（entry point），到這裡表示 kernel 的開機已經進入作業系統核心的部份（OS booting），並且完成了機器平臺（architectural）的初始化與設定工作。



用一句簡單的話來解釋：我們已經脫離 arch/ 目錄啦！start_kernel() 也被解釋為作業系統（operating system、linux kernel）的進入點。

Initialization Sequence

在 main.c 裡的 start_kernel() 函數實作中，我們能看到一大串的「initialization」函數呼叫。這些初始化函數的呼叫是有順序關係的，因此是「initialization sequence」。

在整個初始化程序中，與 scheduler 有關的初始化函數說明如下。

Scheduler Initialization Sequence


我們先來說明一下這 3 個初始化函數的主要目的，再深入討論其內部實作：

1. sched_init()：初始化排程器，包含：初始化 run queue、初始化 “idle thread”。
2. pidhash_init()：初始化 “PID” 的 hash table。
3. fork_init()：計算 kernel 能 “fork” 的最大 process 數量。

Keywords

operating system, process, scheduling, Linux kernel, scheduler, context switch, ELF, process creation, run queue, idle thread, PID,

跟上我們的腳步：請先行閱讀以下的文章，再看這篇日記！

2006.10.22: Jollen 的 Linux 核心分享包,#1: 《開工篇》

]]> https://www.jollen.org/blog/2006/10/jollen_linux_1_15.html https://www.jollen.org/blog/2006/10/jollen_linux_1_15.html Linux Device Drivers & Kernel Tue, 24 Oct 2006 22:33:10 +0800 http://www-128.ibm.com/developerworks/linux/library/l-jfs.html 另外 XFS 是由 SGI 所發展。我們選擇目前較受觀迎的 ReiserFS 來做介紹。 ReiserFS 的特點 ReiserFS 官方網站：http://www.namesys.com/。 日誌式檔案系統被認為相當適合應用在大型的商業伺服器環境中。在這類的環境裡，資料完整性相當的重要。 日誌式檔案系統有著資料庫管理系統 (DBMS) 的交易機制 (Transaction) 特性，一連串的動作如果中間發生錯誤而中斷，資料可以被還原成原來的狀態，可確保資料不會因為未完成，而發生資料不完整的情形。 日誌式檔案會在分割區記錄使用資訊，檔案的寫入動作會先被記錄到記錄檔裡，進行寫入動作時如果中途發生中斷 (例如當機)，而重新啟動電腦時，日誌式的檔案系統會根據記錄檔將先前未完成的動作做回覆 (roll back)，因此可以保證資料不會因為寫入時發生的中斷，而產生不完整的資料。 安裝 ＲeiserFS V4 ReiserFS 目前搭載於 kernel 2.4 的是 V3 版，搭載於 kernel 2.6 的是 V4 版。Kernel 的 patch、設定與安裝可參考： http://www.namesys.com/install_v4.html 另外，也需要用到 reiser4progs 工具程式，下載位置： ftp://ftp.namesys.com/pub/reiser4progs/libaal-1.0.5.tar.gz ftp://ftp.namesys.com/pub/reiser4progs/reiser4progs-1.0.5.tar.gz 要製作 reiser4 的分割區的話只要使用 mkfs.reiser4 工具即可： linux# mkfs.reiser4 /dev/hda5 (範例) 要 mount reiserfs 分割區時，必須加上 -t reiser4 的參數: linux# mount -t reiser4 /dev/hda5 /home2 如果要對 reiserfs 分割區做檢查，只要使用 fsck.reiser4 指令即可。]]> https://www.jollen.org/blog/2006/10/reiserfs_1.html https://www.jollen.org/blog/2006/10/reiserfs_1.html Linux Device Drivers & Kernel Tue, 24 Oct 2006 11:22:48 +0800 http://www.gnu.org/software/gv/ gv 的使用 我們可以在 X Window System 底下直接下命令，例如： linux# gv Trans.PS.gz 這是利用 gv 觀看 Trans.PS.gz 文件的範例，特別的是，經由 gzip 壓縮過的 PostScript 或 PDF 文件不需解壓即可直接利用 gv 閱讀，非常的方便。 利用 gv 也可以閱讀 PDF 文件，例如： linux# gv imug.pdf gv 命令列的參數： □ -ad 讀取 資源檔。-ad 參數的優先權較 -style 來得高。 □ -antialias，-noantialias 是否要使用 antialiasing 功能。 □ -arguments gv 是 ghostscript 的 front-end，在這裡的 是要傳給 ghostscript 的參數。 □ -center，-nocenter 是否要使用自動置中功能。 □ -dsc，-nodsc 是否要使用 DSC (document structuring convention)。如果不使用 DSC (-nodsc)，gv 就不會檢查文件的結構，並且直接將整個檔案傳給 ghostscript。在 -nodsc 模式下，閱讀文件時不會有頁數顯示，而且無法在文件裡移動。 □ -eof，-noeof 使用 -eof 時，當遇到結束的註解時，即表示文件的結束。有些文件，例如將兩個文件合併，雖然有結束的註解，但不表示檔案的結束，這時加上 -noeof 參數才能閱讀全部內容。 □ -pixmap，-nopixmap 如果使用 -pixmap 參數，gv 會以 pixmap 的方式將顯示過的內容保存下來，反之，-nopixmap 參數表示是由 X Server 負責這項工作，而不是 gv。 □ -v 查詢版本編號。 □ -h，-? 顯示求助畫面 (參數用法)。 □ -help 顯示較清楚的求助畫面。 □ -scale 是一個整數，指定文件的放大倍數。 □ -scalebase 設定預設的放大倍數。 □ -monochrome, -grayscale, -color 設定調色盤，即文件的顏色樣式。 □ -media 設定紙張大小。 □ -page 指定文件的標名。 □ -portrait，-landscape，-seascape，-upsidedown 設定文件的顯示位置。 □ -quiet，-noquiet 是否要以 -dQUIET 參數執行 ghostscript。 □ -resize，-noresize 設定gv是否可以自動依視窗大小調整文件的大小。 □ -safer，-nosafer 是否要以 -dSAFER 參數執行 ghostscript。 □ -spartan 和 -style gv_spartan.dat 同義。 □ -style 指定設定檔 (resource file)。這個參數的優先權比 -ad 高。 □ -swap，-noswap 是否要交換 landscape 與 seascape 的顯示方式。 □ -watch，-nowatch 使用 -watch 參數的話，預設是 gv 每一秒會檢查一次文件內容是否有改變，如果有的話，gv 即顯示新的內容。 gv 的設定 如果嫌每次都要打一堆煩人的參數，其實我們可以把這些常用的參數編輯在一個檔案裡 (resource file)。 gv 會先使用由 XFILESEARCHPATH 環境變數所指定的 resource file，如果沒有 XFILESEARCHPATH 環境變數，則使用 /usr/X11R6/lib/X11/app-defaults/GV，系統資源檔可以設定 gv 的預設執行環境。 我們可以依我們平時閱讀的習慣來設定自己的 gv 環境，個人化的 resource file 位於 ~/.gv，gv 會優先使用 ~/.gv 這個 resource file。 gv 也有提供我們 resource file 的設定範例，請由 /usr/X11R6/lib/X11/gv/ 將 gv_user.ad 複製到 ~/.gv： linux# cp /usr/X11R6/lib/X11/gv/gv_user.ad ~/.gv GNU gv 提供以下 3 個設定範例： 1. /usr/X11R6/lib/X11/gv/gv_class.ad 2. /usr/X11R6/lib/X11/gv/gv_system.ad 3. /usr/X11R6/lib/X11/gv/gv_user.ad gv_user.ad 是 gv 個人 resource file 的設定範例，gv_system.ad 是系統 resource file 的設定範例，但新裝好的 gv，實際上這兩個檔案內容是一樣的。 gv 的 resource file (gv_user.ad)：

! ! gv_user.ad ! User specific application defaults for gv ! Copyright (C) 1995, 1996, 1997 Johannes Plass ! !########## gv_user_res.dat !##### Application specific Resources GV.pageMedia: automatic GV.orientation: automatic GV.fallbackOrientation: portrait GV.swapLandscape: False GV.autoCenter: True GV.antialias: True GV.respectDSC: True GV.ignoreEOF: True GV.confirmPrint: True GV.reverseScrolling: False GV.scrollingEyeGuide: True GV.autoResize: True GV.maximumWidth: screen-20 GV.maximumHeight: screen-44 GV.minimumWidth: 400 GV.minimumHeight: 430 GV.confirmQuit: 1 GV.watchFile: False GV.watchFileFrequency: 1000 GV.showTitle: True GV.miscMenuEntries: redisplay \n\ # update \n\ stop \n\ line \n\ toggle_current \n\ toggle_even \n\ toggle_odd \n\ unmark \n\ line \n\ print_all \n\ print_marked \n\ save_all \n\ save_marked GV.scale: 0 GV.scaleBase: 1 GV.scales: Natural size, 1.000, screen \n\ Pixel based, 1.000, pixel \n\ 0.100, 0.100 \n\ 0.125, 0.125 \n\ 0.250, 0.250 \n\ 0.500, 0.500 \n\ 0.707, 0.707 \n\ 1.000, 1.000 \n\ 1.414, 1.414 \n\ 2.000, 2.000 \n\ 4.000, 4.000 \n\ 8.000, 8.000 \n\ 10.00, 10.00 GV.medias: Letter, 612 792 \n\ # LetterSmall, 612 792 \n\ Legal, 612 1008 \n\ Statement, 396 612 \n\ Tabloid, 792 1224 \n\ Ledger, 1224 792 \n\ Folio, 612 936 \n\ Quarto, 610 780 \n\ # 7x9, 504 648 \n\ # 9x11, 648 792 \n\ # 9x12, 648 864 \n\ # 10x13, 720 936 \n\ 10x14, 720 1008 \n\ Executive, 540 720 \n\ # A0, 2384 3370 \n\ # A1, 1684 2384 \n\ # A2, 1191 1684 \n\ A3, 842 1191 \n\ A4, 595 842 \n\ # A4Small, 595 842 \n\ A5, 420 595 \n\ # A6, 297 420 \n\ # A7, 210 297 \n\ # A8, 148 210 \n\ # A9, 105 148 \n\ # A10, 73 105 \n\ # B0, 2920 4127 \n\ # B1, 2064 2920 \n\ # B2, 1460 2064 \n\ # B3, 1032 1460 \n\ B4, 729 1032 \n\ B5, 516 729 \n\ # B6, 363 516 \n\ # B7, 258 363 \n\ # B8, 181 258 \n\ # B9, 127 181 \n\ # B10, 91 127 \n\ # ISOB0, 2835 4008 \n\ # ISOB1, 2004 2835 \n\ # ISOB2, 1417 2004 \n\ # ISOB3, 1001 1417 \n\ # ISOB4, 709 1001 \n\ # ISOB5, 499 709 \n\ # ISOB6, 354 499 \n\ # ISOB7, 249 354 \n\ # ISOB8, 176 249 \n\ # ISOB9, 125 176 \n\ # ISOB10, 88 125 \n\ # C0, 2599 3676 \n\ # C1, 1837 2599 \n\ # C2, 1298 1837 \n\ # C3, 918 1296 \n\ # C4, 649 918 \n\ # C5, 459 649 \n\ # C6, 323 459 \n\ # C7, 230 323 \n\ # DL, 312 624 GV.magMenu: 2, 2 \n\ 4, 4 \n\ 8, 8 \n\ 16, 16 \n\ 32, 32 \n\ 64, 64 !##### Ghostview Widget GV*Ghostview.background: white GV*Ghostview.foreground: black !########## gv_intern_res.dat (generated by makefile) GV.gsInterpreter: gs GV.gsCmdScanPDF: gs -dNODISPLAY -dQUIET -sPDFname=%s -sDSCname=%s pdf2dsc.ps -c quit GV.gsCmdConvPDF: gs -dNODISPLAY -dQUIET -dNOPAUSE -sPSFile=%s %s -c quit GV.gsX11Device: -sDEVICE=x11 GV.gsX11AlphaDevice: -dNOPLATFONTS -sDEVICE=x11alpha GV.gsSafer: True GV.gsQuiet: True GV.gsArguments: GV.uncompressCommand: gzip -d -c %s > %s GV.printCommand: lpr !########## gv_make_res.dat (generated by makefile) GV.scratchDir: ~/ GV.defaultSaveDir: ~/ GV.fallbackPageMedia: letter GV.useBackingPixmap: True GV*dirs: Home\n\ Tmp\n\ /usr/doc\n\ /usr/local/doc GV*filter: no .* GV*filters: None\n\ *.*ps* *.pdf* no .*\n\ *.*ps* no .*\n\ *.pdf* no .*\n\ no .*

設定說明 □ antialias 是否使用 antialias 功能 (True/False)。 □ autoCenter 是否使用自動置中功能 (True/False)。 □ autoResize 是否依照目前文件的頁面大小來調整視窗 (True/False)。 □ confirmPrint 列印時是否需要額外的確認 (True/False)。 □ confirmQuit 離開時是否要確認 (0/1/2)。預設值是 1 表示文件內容有變更時 (例如轉換格式) 才確認，0 表示永遠做不確認，2 表示每次離開時都做確認。 □ scrollingEyeGuide 利用鍵盤捲動文件時是否提示上一頁的部份，使用這個參數，在捲動文件時才能分辨的出那些內容是上一頁的舊內容 (True/False)。 □ ignoreEOF 是否忽略 EOF，當 gv 遇到結束的註解時，並不表示檔案的結束，可能文件中間來雜了 EOF，設定 ignoreEOF=True 時才能完全閱讀這樣的文件 (True/False)。 □ respectDSC 是否要使用 DSC (document structuring convention)。如果不使用 DSC，gv 就不會檢查文件的結構，並且直接將整個檔案傳給 ghostscript (True/False)。在 respectDSC=False 時，閱讀文件時不會有頁數顯示，而且無法在文件裡移動。 □ swapLandscape landscape 與 seacape 的義意是否要互相交換 (True/False)。 □ scratchDir 設定一個暫存目錄。 □ defaultSaveDir 設定一個預設的存檔目錄。 □ useBackingPixmap False 表示由 X Server 負責暫存顯示過的內容。True 則是由 gv 以 pixmap 方式暫存顯示過的內容。 □ watchFile 是否要自動檢查文件的改變 (True/False)。 □ watchFileFrequency 設定檢查文件的時間間隔，單位為 milliseconds，這個值必須大於 500 (milliseconds)。當 WathFile 為 True 時這個設定才有效。 □ printCommand 設定列印文件的指令，%s 巨集可用在這個指令的參數上，表示要列印的文件檔名。 □ gsInterpreter 啟動 ghostscript interpreter 的命令。 □ gsCmdScanPDF 由 PDF 格式的檔案中讀取 DSC 的命令。 □ gsCmdConvPDF 將 PDF 的格式轉換成 PostScript 的命令。 □ gsX11Device 啟動 X11 的命令。 □ gsX11AlphaDevice 當 antialiasing 啟動時，執行 X11 的命令。 □ gsSafer 確認 ghostscript 是否應該以 -dSAFER 的參數啟動。 □ gsQuiet 確認 ghostscript 是否應該以 -dQUIET 的參數啟動。 □ gsArguments 設定要傳給 ghostscript 的參數。 □ dirs 設定在目錄列表時可以選擇的目錄。 □ filter 設定 gv 的目錄列表方式，語法： <filespecs> [no <filespecs>] 例如： GV*filter: *.ps *.pdf no .* 表示只列出 *.ps 與 *.pdf 的檔案，但不列出 "." 開頭的檔案 (隱藏檔)。 □ filters 設定 Fliters 選單中可用的目錄列表方式。 □ miscMenuEntries 設定在文件上按滑鼠右鍵的彈跳視窗內容(update/redisplay/toggle_current/toggle_even/toggle_odd/unmark/stop/print_all/print_marked/save_all/save_marked/line)。 □ showTitle 是否在 title 上顯示目前所閱讀的文件名稱。 □ maximumWidth, maximumHeight 設定主視窗的最小寬度與高度，必須是正整數，最大當然是螢幕的解析度設定。 □ minimumWidth, minimumHeight 設定主視窗的最小寬度與高度，必須是大於 200 的正整數。 □ scale 設定放大倍數。 □ scaleBase 設定預設的放大倍數，必須為正整數。 □ scales 設定在 Scale 選單中的可用的閱讀放大倍數。 □ orientation 設定預設的文件顯示位置 (portrait/landscape/seascape/upside-down/automatic)。automatic 表示由 DSC 取得。 □ fallbackOrientation 設定自動偵測失敗時的預設紙張大小，value 有 portrait/landscape/seascape/upside-down。 □ medias 設定紙張大小，在 gv 的 Media 選單中可以選擇，如果是以 "!" 或 "#" 開始，表示不列入 Media 的選單中，但仍可以被自動偵測並使用。 □ pagemedia 設定紙張大小，value 為在 paper-sizes 中的設定。value 為 automatic 的話，gv 會試著由 DSC 自動偵測大小。 □ fallbackPageMedia 設定紙張大小，value 為在 paper-sizes 中的設定。當自動偵測失敗時就使用這裡設定的大小。 gv 的操作 底下只是基本常用的按鍵，其它 gv 的操作熱鍵請參考 man gv。 □ O 開啟新檔案 □ Q 離開 gv □ shift-ctrl-P 列印目檔的文件 □ ctrl-L 重新顯示目前這一頁 □ . 重新顯示目前這一頁 □ V 把目前文件置中 □ Home 跳到第一頁 □ End 跳到最後一頁 □ shift-up 把文件往上捲，或移動 -1 頁 □ shift-left 把文件往左移，或移動 -1 頁 □ shift-down 把文件往下捲，或移動 1 頁 □ shift-right 把文件往右移，或移動 1 頁 □ shift-up 移動 -1 頁 □ shift-down 移動 1 頁 □ c-Enter 移動 -1 頁 □ s-Enter 移動 -1 頁 □ Enter 移動 1 頁 □ B 移動 -1 頁 □ F 移動 1 頁 □ ctrl-left 移動 -5 頁 □ ctrl-right 移動 5 頁 □Insert 移動 -5 頁 □ Delete 移動 5 頁]]> https://www.jollen.org/blog/2006/10/gnu_gv.html https://www.jollen.org/blog/2006/10/gnu_gv.html Embedded Linux: Platforms and Applications Mon, 23 Oct 2006 16:23:55 +0800 網路上已經有人發表初步的 ext4 filesystem benchmark 數據了，該測試報告的作者將 ext4 的 "extents" 模式開啟，I/O scheduler 為 CFQ。CFQ 是 kernel 2.6.18 之後預設的 I/O 排程法。

由這篇測試報告來看，ext4 在「寫入」的效能表現上，大幅領先 ext3 與 raiser4；不過在其它測試項，ext4 則是與 ext3/raiser4 互有領先。但是整體來看，ext4 的整體效能表現確實比 ext3 來得優秀。

該測試報告也提到，由於 ext4 仍在開發測試階段，一切都要等穩定版出現後，再來做更進一步的評估了。測試報告原文：

http://linux.inet.hr/first_benchmarks_of_the_ext4_file_system.html

Linux-kernel mailing list 也有討論串：

http://forum.jollen.org/index.php?showtopic=6705

Also See

2006.10.13: ext4 檔案系統現身了！

]]> https://www.jollen.org/blog/2006/10/_ext4_filesystem_benchmark_1.html https://www.jollen.org/blog/2006/10/_ext4_filesystem_benchmark_1.html Linux Device Drivers & Kernel Mon, 23 Oct 2006 11:15:53 +0800 Jollen 計畫在自己的 Blog 陸續與大與分享一些 Linux kernel 的研究心得，我們的寫作方向是以重點式的心得整理為主，不過希望加入一些教學性的風格，希望對大家有幫助。到目前為止，我們與大家分享了 Linux system call service 的幾篇日記，接下來仍會再討論幾個系統服務。
故事是這樣開始的

「Linux System Calls' Forum（LSCT）」旨在討論重要的系統服務（system service），以便將來我們能用最有效率的方式研究 kernel；「Jollen 的 Linux 核心分享包」則是在討論 Linux kernel 與作業系統有關的主題，方向是「討論 kernel 實作」。

Jollen 打算以「講義配合 Blog 開講」的方式跟大家一起玩核心！「一份講義」會以多篇日記方式跟大家討論，這裡的講義是從以前的筆記、演講、內訓課程或是討論會節錄並整理而成（需要時當然也會重新編製），Jollen 打算以講義的形式來整理，因此可能並不適合當做「教材」來使用；因此，在與朋友分享這份講義的同時，也要請大家一同分享 Jollen's Blog 網站。

第一份講義請由本文最後的網址下載，在開始看 kernel 前，以下的準備工作是很重要的：

1. 準備一份 Linux 2.6.11 以上的 kernel source code。請參考以下的幾張投影片，大略了解 kernel code 的分佈與原始碼結構。
2. 準備 Source Insight。這個工具非常熱門，所以我想大家都己經有了！
3. 先備知識（enabling technology）：作業系統原理是一定要啦。大家在學校都修過這門必修課，不過日記偶而也會提到參考章節，所以可以的話，也能準備一份在手邊。

發佈計畫

以目前的手稿整理狀況來看，大約會以一星期 1~2 篇日記的進度刊出，第一份講義計畫以 10 篇的篇幅來講解。

Kernel Source 結構



重要目錄：

• System Call Interfaces: 實作程式碼散落於各目錄
• Network System: net/ 目錄
• File System: fs/ 目錄
• Memory Management: mm/ 目錄, 一些 helper-routine 實作於 arch/ 目錄
• Process Management: 大部份實作於 kernel/ 目錄
• Interprocess Communication: ipc/ 目錄
• Device Drivers: drivers/ 目錄
• SELinux (Security Enhanced Linux): security/ 目錄 (only kernel 2.6 or kernel 2.4 for mobile phone)

下載講義

Jollen Blog_Linux Kernel_01_Process Scheduling Introduction.pdf (522 KB)

本系列專欄旨在銜接以下的文章

2006.10.20: Linux System Calls' Forum, #6：(第97號系統服務) sys_setpriority 2006.10.19: Linux System Calls' Forum, #5：(第96號系統服務) sys_getpriority 2006.10.15: Linux System Calls' Forum, #4：(第34號系統服務) sys_nice 2006.10.14: Linux System Calls' Forum, #3：(第64號系統服務) sys_getppid 2006.10.12: Linux System Calls' Forum, #2：(第199,201,200,202,224號系統服務) sys_getuid, sys_geteuid, sys_getgid, sys_getegid, sys_gettid 2006.10.11: Linux System Calls' Forum, #1：(第20號系統服務) sys_getpid

]]> https://www.jollen.org/blog/2006/10/jollen_linux_1_1.html https://www.jollen.org/blog/2006/10/jollen_linux_1_1.html Linux Device Drivers & Kernel Sun, 22 Oct 2006 21:04:21 +0800 了解 sys_getpriority() 後，要看懂 sys_setpriority() 就不是問題了。

97	sys_setpriority	linux/kernel/sys.c
類別：Systems 原型宣告：long sys_setpriority(int which, int who, int niceval); 用途說明：變更 process 的排程優先序（Priority）。
Kernel (2.6.11 or above) 實作： asmlinkage long sys_setpriority(int which, int who, int niceval) { struct task_struct *g, *p; struct user_struct *user; int error = -EINVAL; if (which > 2 || which < 0) goto out; /* normalize: avoid signed division (rounding problems) */ error = -ESRCH; if (niceval < -20) niceval = -20; if (niceval > 19) niceval = 19; read_lock(&tasklist_lock); switch (which) { case PRIO_PROCESS: if (!who) who = current->pid; p = find_task_by_pid(who); if (p) error = set_one_prio(p, niceval, error); break; case PRIO_PGRP: if (!who) who = process_group(current); do_each_task_pid(who, PIDTYPE_PGID, p) { error = set_one_prio(p, niceval, error); } while_each_task_pid(who, PIDTYPE_PGID, p); break; case PRIO_USER: user = current->user; if (!who) who = current->uid; else if ((who != current->uid) && !(user = find_user(who))) goto out_unlock; /* No processes for this user */ do_each_thread(g, p) if (p->uid == who) error = set_one_prio(p, niceval, error); while_each_thread(g, p); if (who != current->uid) free_uid(user); /* For find_user() */ break; } out_unlock: read_unlock(&tasklist_lock); out: return error; }

Jollen 的說明

程式一開始先判斷 which 參數的正確性，並且將 user process 所指定的 nice 值限定在 [-20..19] 的範圍內：

	if (which > 2 || which < 0)
		goto out;

	/* normalize: avoid signed division (rounding problems) */
	error = -ESRCH;
	if (niceval < -20)
		niceval = -20;
	if (niceval > 19)
		niceval = 19;

底下我們來討論 PRIO_PROCESS 與 PRIO_PGRP 參數的實作，強烈建議您先行閱讀本文最後所整理的文章，再回頭來看以下的說明，才能得到最佳學習效果。

變更 priority：PRIO_PROCESS

主要的程式片斷如下：

	case PRIO_PROCESS:   /* 請看 1. */
		if (!who)
			who = current->pid;   /* 請看 1. */
		p = find_task_by_pid(who);   /* 請看 2. */
		if (p)   /* 請看 3. */
			error = set_one_prio(p, niceval, error);   /* 請看 3. */
		break;

說明：

1. 若 which = PRIO_PROCESS，則 who 的值就是 process ID。因為 who 不能為 0，所以如果 who 是 0 的話，就指定為 current 的 PID。
2. find_task_by_pid() 是 kernel API，用來取得 PID 的 process descriptor。我們已經學過了！
3. 如果 p 不是 NULL，就呼叫 set_one_prio()，修改 p 的「nice 值」為 niceval。

變更 priority：PRIO_PGRP

主要的程式片斷如下：

	case PRIO_PGRP:
		if (!who)
			who = process_group(current);
		do_each_task_pid(who, PIDTYPE_PGID, p) {   /* 請看 1. */
			error = set_one_prio(p, niceval, error);   /* 請看 1. */
		} while_each_task_pid(who, PIDTYPE_PGID, p);   /* 請看 1. */
		break;

說明：

1. 在迴圈裡，逐一修改 process group 裡的 process，將其優先序變更為 niceval。這樣的迴圈，在 sys_getpriority() 也看過一次！

二段 kernel code 都呼叫到此 kernel API：

• kernel API - set_one_prio()：傳入 process descriptor 與新的 nice 值，將 process 的 priorioty 做變更。

TIP

"*_PGRP"（process group）是 kernel 2.4 的 sematics，「current->pgrp」是 kernel 2.4 的寫法。我們未來有機會的話再做說明。

　

跟上我們的腳步：請讀以下的文章，再看這篇日記！

Linux System Calls' Forum, #5：(第96號系統服務) sys_getpriority

]]> https://www.jollen.org/blog/2006/10/linux_system_calls_forum_697_s.html https://www.jollen.org/blog/2006/10/linux_system_calls_forum_697_s.html Linux Device Drivers & Kernel Fri, 20 Oct 2006 19:38:13 +0800 getpriority() 若指定 which 是 PRIO_PGRP 的話，那麼便能取得 process group 裡的「最大 priority 值」。先節錄相關 kernel code 如下：

asmlinkage long sys_getpriority(int which, int who)
{
		...
		case PRIO_PGRP:
			if (!who)
				who = process_group(current);
			do_each_task_pid(who, PIDTYPE_PGID, p) {
				niceval = 20 - task_nice(p);
				if (niceval > retval)
					retval = niceval;
			} while_each_task_pid(who, PIDTYPE_PGID, p);
			break;
		...
}

接續昨天的 sys_getpriority()，讓我們再來看一下 PRIO_PGRP 參數的實作：

1. 如果 who 是 0 的話，先呼叫 process_group() 取得 group ID。
2. 使用 do_each_task_pid 與 while_each_task_pid 巨集做迴圈。
3. 在迴圈裡面，呼叫 task_nice() 取得 process 的 priority，然後判斷目前的 nice 值是否大於先前的 nice 值。這麼做的用意是「找到 process group 裡最大的 nice 值 (lowest priority) 後回傳」。

跟上我們的腳步：請讀以下的文章，再看這篇日記！

Linux System Calls' Forum, #5：(第96號系統服務) sys_getpriority

]]> https://www.jollen.org/blog/2006/10/_sys_getpriority.html https://www.jollen.org/blog/2006/10/_sys_getpriority.html Linux Device Drivers & Kernel Fri, 20 Oct 2006 16:13:25 +0800 Virtual Machine Monitor (VMM) 軟體實作的虛擬機器在此技術領域中被統稱為「VMM - Virtual Machine Monitor」，現在已經有支援 Intel Virtualization Technology 的 VMM 了，那就是知名的 Xen。相關的參考網址如下： Extending Xen with Intel Virtualization Technology - http://www.intel.com/technology/itj/2006/v10i3/3-xen/1-abstract.htm Xen - http://www.xensource.com/index.html 接下來，就是我們今天在網路上所看到的重點了！ KVM: Kernel-based Virtual Machine 今天，看到了 2.6 kernel 的 KVM patch。KVM（Kernel Virtual Machine）是 Intel's virtualization technology 的驅動程式！KVM 驅動程式目前支援 i386 與 x86_64 "host"，且「All combinations are allowed except x86_64 guest on i386 host.」。 比較特殊的是 Linux 2.6 的 KVM 驅動程式支援三種模式：kernel mode、user mode 與 guest mode。KVM 驅動程式的 user-space 介面是 '/dev/kvm'，因此 process 可以執行自己的 virtual machine，在一台電腦上也能執行多個 virtual machine。Guest mode：

「Guest mode has its own address space mapping guest physical memory (which is accessible to user mode by mmap()ing /dev/kvm). Guest mode has no access to any I/O devices; any such access is intercepted and directed to user mode for emulation. 」。

取得 Patch 與追踪主題 [PATCH 0/7] KVM: Kernel-based Virtual Machine [PATCH 1/7] KVM: userspace interface [PATCH 2/7] KVM: Intel virtual mode extensions definitions [PATCH 3/7] KVM: kvm data structures [PATCH 5/7] KVM: mmu virtualization [PATCH 6/7] KVM: x86 emulator [PATCH 7/7] KVM: plumbing 關於更多 Intel 的 Virtualization Technology 可以參考的網址如下： Make virtualization a reality - http://www.intel.com/cd/channel/reseller/asmo-na/eng/products/server/processors/250640.htm Server Virtualization Technology - http://www.intel.com/business/bss/products/server/virtualization_wp.pdf ]]> https://www.jollen.org/blog/2006/10/kernel_26_kvm_kernel_virtual_m.html https://www.jollen.org/blog/2006/10/kernel_26_kvm_kernel_virtual_m.html Linux Device Drivers & Kernel Thu, 19 Oct 2006 23:27:51 +0800 nice() 是用來變更 process 優先序（priority）的 system call 也是最古老的一個，sys_getpriority() 與 sys_setpriority() 則是取代 sys_nice() 的新實作，今天我們先討論一下 'sys_getpriority'。

96	sys_getpriority	linux/kernel/sys.c
類別：Systems 原型宣告：long sys_getpriority(int which, int who); 用途說明：取得 process 的排程優先序（Priority）。
Kernel (2.6.11 or above) 實作： /* * Ugh. To avoid negative return values, "getpriority()" will * not return the normal nice-value, but a negated value that * has been offset by 20 (ie it returns 40..1 instead of -20..19) * to stay compatible. */ asmlinkage long sys_getpriority(int which, int who) { struct task_struct *g, *p; struct user_struct *user; long niceval, retval = -ESRCH; if (which > 2 || which < 0) return -EINVAL; read_lock(&tasklist_lock); switch (which) { case PRIO_PROCESS: if (!who) who = current->pid; p = find_task_by_pid(who); if (p) { niceval = 20 - task_nice(p); if (niceval > retval) retval = niceval; } break; case PRIO_PGRP: if (!who) who = process_group(current); do_each_task_pid(who, PIDTYPE_PGID, p) { niceval = 20 - task_nice(p); if (niceval > retval) retval = niceval; } while_each_task_pid(who, PIDTYPE_PGID, p); break; case PRIO_USER: user = current->user; if (!who) who = current->uid; else if ((who != current->uid) && !(user = find_user(who))) goto out_unlock; /* No processes for this user */ do_each_thread(g, p) if (p->uid == who) { niceval = 20 - task_nice(p); if (niceval > retval) retval = niceval; } while_each_thread(g, p); if (who != current->uid) free_uid(user); /* for find_user() */ break; } out_unlock: read_unlock(&tasklist_lock); return retval; }

Jollen 的說明

讓我們來看一下 system call service - 'sys_getpriority' 的程式實作。首先是 sys_getpriority() 的參數：which 與 who，這二個參數對應到 getpriority() 的 which 與 who 參數；如果您不是很清楚 which/who 的話，請參閱前幾天的日記。

我們拿底下的程式片斷來討論：

	switch (which) { /* 請看 1. */
		case PRIO_PROCESS: /* 請看 2. */
			if (!who) /* 請看 2. */
				who = current->pid;
			p = find_task_by_pid(who); /* 請看 3. */
			if (p) { /* 請看 4. */
				niceval = 20 - task_nice(p); /* 請看 5. */
				if (niceval > retval)
					retval = niceval;
			}
			break;
		...
	}

說明如下：

1. 判斷 which 參數，假設我們想要取得 process 的 priority，那麼 which 的值就是 PRIO_PROCESS。
2. 若 which = PRIO_PROCESS，則 who 的值就是 process ID。因為 who 不應該為 0，所以如果 who 是 0 的話，就指定為 current 的 PID。
3. find_task_by_pid() 是 kernel API，用來取得 PID 的 process descriptor。
4. 如果 p 不是 NULL，就呼叫 task_nice()，取得 process 的「nice 值」，然後傳回 nice 值。
5. kernel 的 nice 值範圍為 [-20..19]，但 user-space 的 nice 值是 [40,1]，所以要做換算：[20-(-20)..20-19] = [40..1]。

喔！要取得 process priority 的 kernel 實作看起來還挺簡單的。我們又學到了：

• kernel API - find_task_by_pid()：傳入 PID，取得該 process 的 process descriptor。
• kernel API - task_nice()：傳入 process descriptor，取得該 process 的 priority（nice 值）。

TIP

所謂的「nice 值」就是 process 的優先序（優先等級、priority）。

　

跟上我們的腳步：請讀以下的文章，再看這篇日記！

Linux System Calls' Forum, #1：(第20號系統服務) sys_getpid Linux System Calls' Forum, #2：(第199,201,200,202,224號系統服務) sys_getuid, sys_geteuid, sys_getgid, sys_getegid, sys_gettid Linux System Calls' Forum, #4：(第34號系統服務) sys_nice getpriority() 與 setpriority() 程式設計

]]> https://www.jollen.org/blog/2006/10/linux_system_calls_forum_596_s.html https://www.jollen.org/blog/2006/10/linux_system_calls_forum_596_s.html Linux Device Drivers & Kernel Thu, 19 Oct 2006 21:07:56 +0800 請按我下載]]> https://www.jollen.org/blog/2006/10/post_3.html https://www.jollen.org/blog/2006/10/post_3.html 其它 Thu, 19 Oct 2006 16:35:19 +0800 是蟲啦，不是警告。在 Linux kernel 的 mailing list 看到一則有意思的張貼，全文如下，Jollen 把重點用紅色標示出來：

* Jeremy Fitzhardinge  wrote:

> A warning is a warning, not a BUG.

> - printk("BUG: warning at %s:%d/%s()n", __FILE__,
> + printk("WARNING at %s:%d %s()n", __FILE__,

i'm not really happy about this change.

Firstly, 
most WARN_ON()s are /bugs/, not warnings ... 
If it's a real
warning, a KERN_INFO printk should be done.

Secondly, the reason i changed it to the 'BUG: ...' format is that i
tried to make it easier for automated tools (and for users) to figure
out that a kernel bug happened.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ 

很重要，一定要看的概念。在 Linux kernel 裡，WARN_ON() 所秀出來的訊息格式為「BUG: xxx」，表示這是一個臭蟲。如果是警告訊息，則是用 loglevel 'KERN_INFO' 來列印訊息。

所以，這位老兄解釋的很清楚，這類的 "warning" 訊息是 kernel 的 "bug"，並不是字面上所表示的「警告」訊息！

]]> https://www.jollen.org/blog/2006/10/post_2.html https://www.jollen.org/blog/2006/10/post_2.html Linux Device Drivers & Kernel Wed, 18 Oct 2006 21:20:09 +0800 前幾天介紹到 Linux 的一個排程（Scheduling）系統服務叫做 sys_nice()，與 sys_nice() 相關的 system call service 是 sys_getpriority() 與 sys_setpriority()，不過在看 kernel code 前，我們應該先試著了解 getpriority() 與 setpriority() 二個 system call 的用法。

先來了解一下 getpriority() 的用途，GETPRIORITY(2)：

SYNOPSIS
       #include <sys/time.h>
       #include <sys/resource.h>

       int getpriority(int which, int who);

getpriority() 的 which 參數用來指定要取得 priority 對象：process、process group 或 user ID。

最容易學習的方式就是讀範例，所以我們將會設計 2 個範例來執行。

which 參數：

• PRIO_PROCESS：who 參數指定 process ID，傳回 process 的 priority。
• PRIO_PGRP：who 參數指定 process group ID，傳回 process group 的 priority。
• PRIO_USER：who 參數指定 user ID，傳回 user 的 priority 。
Jollen 寫了二個程式：setpriority.c 與 getpriority.c。先來測試一下。

實測結果

隨便找一個對象下手：

# ps ax
...
17349 ?        S      0:02 [httpd]
...

把 PID 17349 的 scheduling priority 往上提升一級：

# ./getpriority 17349
Process (17349) Priority is 0.
# ./setpriority
Usage: ./setpriority [pid] [priority (-20~19)]
# ./setpriority 17349 -1
OK.
# ./getpriority 17349
Process (17349) Priority is -1.

另外，系統指令 nice 可以用來設定執行命令的 process priority：

NICE(1)                               FSF                              NICE(1)

NAME
       nice - run a program with modified scheduling priority

SYNOPSIS
       nice [OPTION] [COMMAND [ARG]...]

DESCRIPTION
       Run  COMMAND  with  an  adjusted scheduling priority.  With no COMMAND,
       print the current scheduling priority.  ADJUST is 10 by default.  Range
       goes from -20 (highest priority) to 19 (lowest).

       -n, --adjustment=ADJUST
              increment priority by ADJUST first

       --help display this help and exit

       --version
              output version information and exit

程式碼

/* Program: getpriority.c */
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/resource.h>

int main(int argc, char *argv[])
{
   /* getpriority() 傳回的類別是 int */
   int prio_process, prio_pgroup, prio_user;
   pid_t pid;

   if (argc != 2)
      return -1;

   pid = atoi(argv[1]);
   prio_process = getpriority(PRIO_PROCESS, pid);

   printf("Process (%d) Priority is %d.\n", pid, prio_process);
   return 0;
}

/* Program: setpriority.c */
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/resource.h>

int main(int argc, char *argv[])
{
   int errno, prio;
   pid_t pid;

   if (argc != 3) {
      printf("Usage: %s [pid] [priority (-20~20)]\n", argv[0]);
      return -1;
   }

   pid = atoi(argv[1]);
   prio = atoi(argv[2]);
   errno = setpriority(PRIO_PROCESS, pid, prio);

   printf("OK.\n");

   return 0;
}

了解 setpriority() 與 getpriority() 後，就可以開始研究 system call service - 'sys_setpriority' 與 'sys_getpriority' 了。]]> https://www.jollen.org/blog/2006/10/getpriority_setpriority.html https://www.jollen.org/blog/2006/10/getpriority_setpriority.html GNU Toolchains & Linux Systems Programming Tue, 17 Oct 2006 22:40:20 +0800 嵌入式 Linux 系統管理 - Software Stack 的設定 如果使用 Red Hat Linux 9 (or Fedora) 預設的 SDL，ffplay 的執行畫面如下圖。 圖一：在 X11 上執行的 ffplay 這時 SDL 的編譯設定 (configure) 應該是類似這樣的：

# ./configure --prefix=/usr --enable-video-x11 --disable-video-fbcon --disable-nano-direct-fb --disable-video-nanox --disable-nanox-share-memory --disable-alsatest --with-nanox-pixel-type=0888

我們修改 configure 參數如下:

# ./configure --prefix=/usr --disable-video-x11 --disable-video-fbcon --enable-nano-direct-fb --enable-video-nanox --enable-nanox-share-memory --disable-alsatest --with-nanox-pixel-type=0888

重新編譯並安裝 SDL 後，ffplay 就能在 Nano-X 的介面下撥放影片。如果 Nano-X 的設定是支援 X11 的話，執行後的結果會是下圖的畫面。 圖二：在 Nano-X 上執行的 ffplay (Nano-X with X11) 我們怎麼讓 ffplay 可以在開機後，直接透過 VGA framebuffer 來撥放影片，而不用再進入 X11 呢？做法是：把 Nano-X 設定成支援 VGA framebuufer 即可（Nano-X with VGA FB），至於 SDL 的話，是不用再做任何調整的了！(why?) 當然 ffplay 也不用變動。所以，關於第 2 點的架構做法，可以再細分成： 2.1 ffplay + SDL + Nano-X + X11 2.2 ffplay + SDL + Nano-X + VGA fb 很值得用來練習編譯設定與觀念討論的例子。 Embedded Linux 的考量 「ffplay + SDL + Nano-X」這個架構是適合 Embedded Linux 使用的，只要讓 Nano-X 能完整支援 target device，並把 SDL 與 FFmpeg 移植到 target device，便能在 target device 上撥放影片檔。]]> https://www.jollen.org/blog/2006/10/embedded_linux_5_configure_sof.html https://www.jollen.org/blog/2006/10/embedded_linux_5_configure_sof.html Embedded Linux: Platforms and Applications Sun, 15 Oct 2006 12:01:46 +0800 nice() 是用來變更 process 優先序（priority）的 system call，nice() system call 叫用（invoke）的 system call 實作常式為 sys_nice。sys_nice 服務常式（service routine）是 Linux 排程（scheduling）相關的服務常式中最基本（也是最古老）的一個。

34	sys_nice	linux/kernel/sched.c
類別：Scheduling 原型宣告：long sys_nice(int increment); 用途說明：變更 process 的優先序。
Kernel (2.6.11 or above) 實作： /* * sys_nice - change the priority of the current process. * @increment: priority increment * * sys_setpriority is a more generic, but much slower function that * does similar things. */ asmlinkage long sys_nice(int increment) { int retval; long nice; /* * Setpriority might change our priority at the same moment. * We don't have to worry. Conceptually one call occurs first * and we have a single winner. */ if (increment < -40) increment = -40; if (increment > 40) increment = 40; nice = PRIO_TO_NICE(current->static_prio) + increment; if (nice < -20) nice = -20; if (nice > 19) nice = 19; if (increment < 0 && !can_nice(current, nice)) return -EPERM; retval = security_task_setnice(current, nice); if (retval) return retval; set_user_nice(current, nice); return 0; }

Jollen 的說明

首先，讓我們先看一下 NICE(2) 的內容：

NAME
       nice - change process priority

SYNOPSIS
       #include 

       int nice(int inc);

DESCRIPTION
       nice  adds  inc  to  the nice value for the calling pid.  (A large nice
       value means a low priority.)  Only the superuser may specify a negative
       increment, or priority increase.

參數 inc 是所要改變的 priority 數量，inc 可以是正數也可以是負數。正數表示 priority 變多（多加上 inc，表示  low priority），若要提升 priority，inc 只要指定為負數即可；根據 NICE(2) 的說明，只有 superuser 才能指定負數，也就是把提高優先序。

nice() 會把 process 的 priority 變更為 "priority+ inc"。

sys_nice() 的實作

以下是 sys_nice() service routine 的原型：

long sys_nice(int increment)

increment 就是前面所提到的 inc 參數（透過 system call 機制傳遞，並非函數呼叫傳值）。increment 的範圍被 kernel 限定在 [40,-40] 的範圍內：

	if (increment < -40)
		increment = -40;
	if (increment > 40)
		increment = 40;

所以如果呼叫 nice() 時，指定的優先改變量超過 [40,-40] 時，是得不到預期效果的。sys_nice 接著先把 process 的 "priority" 數值轉算成 "nice" 值，然後再加上 increment（因為 increment 是一個 "nice" 值，不是 "priority" 值）：

	nice = PRIO_TO_NICE(current->static_prio) + increment;

得到的 "nice" 值，必須限定在 [19,-20] 的範圍內：

	if (nice < -20)
		nice = -20;
	if (nice > 19)
		nice = 19;

再來，如果 increment 小於 0，也就是 user 的 "nice" 值是負的，那就要檢查是不是可以變更此 process 的 "priority"：

	if (increment < 0 && !can_nice(current, nice))
		return -EPERM;　

不過這裡的重點是 can_nice() 所呼叫的 kernel API - capable()，並非 can_nice() 本身，再追一下 can_nice() 的原始碼可以找到這段：

capable(CAP_SYS_NICE)

capable() 用來檢查 process 的 "capability"，不過我們先在這裡略過這個主題。

Process capability 若允許變更 priority，就修改 process 的 priority，否則 return -EPERM。

更多關於 sys_nice()

sys_nice() 目前大概是為了要向後相容而持續存在於 Linux 原始碼裡，目前已經推薦改用 sys_setpriority() 服務常式了。因此在 Linux programming 上，我們也要改用 setpriority() system call 來取代 nice()。以下是 GETPRIORITY(2)：

NAME
       getpriority, setpriority - get/set program scheduling priority

SYNOPSIS
       #include 
       #include 

       int getpriority(int which, int who);
       int setpriority(int which, int who, int prio);

TIP 　　"priority" 表示 process 的優先序，數字越大表示優先序越低；"nice" 指的是要改變的 priority 量，例如 -10 表示要把 priority 減少 10，即提高優先序。

--jollen

作者／陳俊宏
http://www.jollen.org

]]> https://www.jollen.org/blog/2006/10/linux_system_calls_forum_434_s.html https://www.jollen.org/blog/2006/10/linux_system_calls_forum_434_s.html Linux Device Drivers & Kernel Sun, 15 Oct 2006 00:55:24 +0800 sys_getppid 是很有趣的一個實作常式。

當 process fork 新的 process 後，便成為該 process 的 parent process，當然，新的 process 便成為 child process。在 UNIX 的 multithreaded 程式設計的理論中，process 之間的關係是相當重要的，比如說，只有 related process (e.g. parent process v.s. child process) 可以透過 pipe 的機制來交換資料。

process 呼叫 fork() 函數（更正確的說法是 fork system call 的 wrapper function）後，fork() 便傳回 child process 的 PID；child process 則可以透過 getppid() system call 來取得 parent process 的 PID。

64	sys_getppid	linux/kernel/timer.c
類別：Kernel Timer & Process 原型宣告：long sys_getppid(void); 用途說明：取得 parent process 的 PID。
Kernel (2.6.11 or above) 實作： /* * Accessing ->group_leader->real_parent is not SMP-safe, it could * change from under us. However, rather than getting any lock * we can use an optimistic algorithm: get the parent * pid, and go back and check that the parent is still * the same. If it has changed (which is extremely unlikely * indeed), we just try again.. * * NOTE! This depends on the fact that even if we _do_ * get an old value of "parent", we can happily dereference * the pointer (it was and remains a dereferencable kernel pointer * no matter what): we just can't necessarily trust the result * until we know that the parent pointer is valid. * * NOTE2: ->group_leader never changes from under us. */ asmlinkage long sys_getppid(void) { int pid; struct task_struct *me = current; struct task_struct *parent; parent = me->group_leader->real_parent; for (;;) { pid = parent->tgid; #if defined(CONFIG_SMP) || defined(CONFIG_PREEMPT) { struct task_struct *old = parent; /* * Make sure we read the pid before re-reading the * parent pointer: */ smp_rmb(); parent = me->group_leader->real_parent; if (old != parent) continue; } #endif break; } return pid; }

Jollen 的說明

Linux kernel 內部的 getppid 實作常式 (routine) - sys_getppid 的程式碼並不難懂， 在這裡我們先忽略 SMP 與 preemptive scheduling 的議題，因此有一段落的程式碼我們故意視而不見，讓我們來討論剩下的程式碼：

asmlinkage long sys_getppid(void) { int pid; struct task_struct *me = current; struct task_struct *parent; parent = me->group_leader->real_parent; for (;;) { pid = parent->tgid; #if defined(CONFIG_SMP) || defined(CONFIG_PREEMPT) { ... } #endif break; } return pid; }

struct task_struct 的 field - 'group_leader' 是一個 pointer，指向 thread (process) group 的 leader；struct task_struct 的 field - 'real_parent' 是一個 pointer，指向 task 的 "real parent"：

struct task_struct {
	...
	/* real parent process (when being debugged) */
	struct task_struct *real_parent;
	struct task_struct *parent; /* parent process */
	...
	/* threadgroup leader */
	struct task_struct *group_leader;
	...
}	

real_parent 與 parent

在 struct task_struct 裡，我們發現一件有趣的事：怎麼會有 real_parent 與 parent 二個 field 呢？

我們姑且不去說明 parent 的用義，real_parent 指的是建立（create）此 process（task）的 process，當建立該 process 的 process（real_parent）已經不存在時（eg. terminate），real_parent 便指向 init process。

好囉，我們知道一件重要的事情了，要找到「我的爸爸」 kernel code 寫法是：

struct task_struct *me = current;   /* 我自己 */

struct task_struct *parent;   /* 我爸 */

parent = me->real_parent;   /* 我真正的爸（生下我的）*/

但這裡的寫法並不正確。讓我們繼續往下討論。

Group Leader

每一個 process 都是某些 process group 的成員，所有的 process group 都有一個帶班的 process（group leader）。比如說，當 GNU/Linux 系統開機時，init process 就是所有 process 的 group leader。

因此 process 的 parent process 應該是「group leader 的 real parent」，所以我們要先索引到 process descriptor 的 group_leader 欄位，然後再索引到 group leader 的 real_parent。

TIP 　　　借用一下作業系統的說法：struct task_struct 就是 process 的 process descriptor。

所以，正確的 kernel code 寫法是：

struct task_struct *me = current;   /* 我自己 */

struct task_struct *parent;   /* 我爸 */

parent = me->group_leader->real_parent;   /* 領班的真正爸，才是我的爸 = = " */

這樣就能理解 Linux 2.6 的 sys_getppid 實作了，雖然有一點不太直覺，不過看起來是頗有學問的設計。知道怎麼找到 parent process 後，再由 process descriptor 裡把 PID 拿出來就行了：

parent->tgid;

作業系統還真是有趣。

--jollen

作者／陳俊宏
http://www.jollen.org

]]> https://www.jollen.org/blog/2006/10/linux_system_calls_forum_364_s.html https://www.jollen.org/blog/2006/10/linux_system_calls_forum_364_s.html Linux Device Drivers & Kernel Sat, 14 Oct 2006 22:49:22 +0800 http://www.linux-watch.com/news/NS3183866977.html '-mm' 系列的 2.6 kernel 是由 Andrew Morton 所釋出的 Linux 分支，主要性質以「實驗」與「新功能」為主；'ext4' 一睹為快，搶鮮下載 (mm patch 下載官網)： ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/ 並且也要下載新的 e2fsprogs 套件： ftp://ftp.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs-interim/ 使用方法 (ftp：//ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/announce.txt)： # mke2fs -j /dev/hda1 (格式化) # mount /dev/hda1 /wherever -t ext4dev (filesystem type 'ext4dev') 如果要使用 'extent' 功能： # mount /dev/hda1 /wherever -t ext4dev -o extents ]]> https://www.jollen.org/blog/2006/10/ext4.html https://www.jollen.org/blog/2006/10/ext4.html Linux Device Drivers & Kernel Fri, 13 Oct 2006 09:29:19 +0800

199	sys_getuid	linux/kernel/timer.c
類別：Kernel Timer & Process 原型宣告：long sys_getuid(void); 用途說明：取得目前 process 的 real user ID (UID)。
Kernel (2.6.11 or above) 實作： asmlinkage long sys_getuid(void) { /* Only we change this so SMP safe */ return current->uid; }




201	sys_geteuid	linux/kernel/timer.c
類別：Kernel Timer & Process 原型宣告：long sys_geteuid(void); 用途說明：取得目前 process 的 effective real user ID (file ID bit)。
Kernel (2.6.11 or above) 實作： asmlinkage long sys_geteuid(void) { /* Only we change this so SMP safe */ return current->euid; }


Jollen 的說明

在 struct task_struct 裡紀錄了 task (process) 的所有資訊，其中我們最為熟悉的 process ID 與 user ID (and group ID) 都可以由這個資料結構裡取得。讓我們來看看 wrapper function 'getuid' 的用法 (from man)：

NAME
       getuid, geteuid - get user identity
                                                                                
SYNOPSIS
       #include 
       #include 
 
       uid_t getuid(void);
       uid_t geteuid(void);
 
DESCRIPTION
       getuid returns the real user ID of the current process.
 
       geteuid returns the effective user ID of the current process.
 
       The  real  ID corresponds to the ID of the calling process.  The effec-
       tive ID corresponds to the set ID bit on the file being executed.

'getuid' 所對應的 system call service 為 sys_getuid，讓我們來看一下 Linux 的實作：

asmlinkage long sys_getuid(void)
{
        /* Only we change this so SMP safe */
        return current->uid;
}

嗯，果然是非常的好懂，只要懂 current 巨集的用途即可！另外，要提醒的是，'current->uid' 並非直接 return 給 user-space 的 wrapper function (getuid in our example)。(那是 return 給誰?)

在 Linux 裡有許多類似 getuid 的 system call 實作，比如 sys_geteuid 的程式碼也是直接回傳 struct task_struct 裡的 field，並不難懂。

以下是 sys_getgid 與 sys_getegid 的整理。

200	sys_getgid	linux/kernel/timer.c
類別：Kernel Timer & Process 原型宣告：long sys_getgid(void); 用途說明：取得目前 process 的 real group ID (GID)。
Kernel (2.6.11 or above) 實作： asmlinkage long sys_getgid(void) { /* Only we change this so SMP safe */ return current->gid; }




202	sys_getegid	linux/kernel/timer.c
類別：Kernel Timer & Process 原型宣告：long sys_getegid(void); 用途說明：取得目前 process 的 effective group ID (EGID)。
Kernel (2.6.11 or above) 實作： asmlinkage long sys_getegid(void) { /* Only we change this so SMP safe */ return current->egid; }

這 4 個 Linux system call 都非常的容易了解，由 Linux System Calls' Forum #1,#2 我們了解到 2 個重要的 Kernel 議題：

• 1. struct task_struct;
• 2. The current macro.

最後還有一個 sys_gettid 的實作。

224	sys_gettid	linux/kernel/timer.c
類別：Kernel Timer & Process 原型宣告：long sys_gettid(void); 用途說明：取得 task 的 "pid"。
Kernel (2.6.11 or above) 實作： /* Thread ID - the internal kernel "pid" */ asmlinkage long sys_gettid(void) { return current->pid; }

]]> https://www.jollen.org/blog/2006/10/linux_system_calls_forum_21992.html https://www.jollen.org/blog/2006/10/linux_system_calls_forum_21992.html Linux Device Drivers & Kernel Thu, 12 Oct 2006 12:57:37 +0800 對於 Linux system call 的研究，我們採取的策略是「依分類」來做討論，而不是依 system call 編號依序討論。透過 system call (kernel-space 端) 的研究，我們除了可以更深入了解作業系統外，更能一探 Linux kernel 的奧妙。

20	sys_getpid	linux/kernel/timer.c
類別：Kernel Timer & Process 原型宣告：long sys_getpid(void); 用途說明：取得目前 process 的 thread ID (process ID)。
Kernel (2.6.11 or above) 實作： /** * sys_getpid - return the thread group id of the current process * * Note, despite the name, this returns the tgid not the pid. The tgid and * the pid are identical unless CLONE_THREAD was specified on clone() in * which case the tgid is the same in all threads of the same group. * * This is SMP safe as current->tgid does not change. */ asmlinkage long sys_getpid(void) { return current->tgid; }

Jollen 的說明

「Linux system calls 討論」系列，我們略過關於 user-space 端的說明，因此大家必須先了解以下主題：

• system call 的 wrapper function (glibc)
• 0x80 號軟體中斷 (i386)

sys_getpid 透過 current 巨集取得目前 process 的 ID，kernel code 都可以存取 current 巨集 (我們把此巨集當做 kernel 的 global symbol 來看) 來存取目前 process 的狀態。

current 的 data structure 為 struct task_struct：

// include/linux/sched.h struct task_struct { volatile long state; /* -1 unrunnable, 0 runnable, >0 stopped */ struct thread_info *thread_info; atomic_t usage; unsigned long flags; /* per process flags, defined below */ unsigned long ptrace; int lock_depth; /* BKL lock depth */ #if defined(CONFIG_SMP) && defined(__ARCH_WANT_UNLOCKED_CTXSW) int oncpu; #endif int prio, static_prio; struct list_head run_list; prio_array_t *array; unsigned short ioprio; unsigned int btrace_seq; unsigned long sleep_avg; unsigned long long timestamp, last_ran; unsigned long long sched_time; /* sched_clock time spent running */ enum sleep_type sleep_type; unsigned long policy; cpumask_t cpus_allowed; unsigned int time_slice, first_time_slice; #ifdef CONFIG_SCHEDSTATS struct sched_info sched_info; #endif struct list_head tasks; /* * ptrace_list/ptrace_children forms the list of my children * that were stolen by a ptracer. */ struct list_head ptrace_children; struct list_head ptrace_list; struct mm_struct *mm, *active_mm; /* task state */ struct linux_binfmt *binfmt; long exit_state; int exit_code, exit_signal; int pdeath_signal; /* The signal sent when the parent dies */ /* ??? */ unsigned long personality; unsigned did_exec:1; pid_t pid; pid_t tgid; /* * pointers to (original) parent process, youngest child, younger sibling, * older sibling, respectively. (p->father can be replaced with * p->parent->pid) */ struct task_struct *real_parent; /* real parent process (when being debugged) */ struct task_struct *parent; /* parent process */ /* * children/sibling forms the list of my children plus the * tasks I'm ptracing. */ struct list_head children; /* list of my children */ struct list_head sibling; /* linkage in my parent's children list */ struct task_struct *group_leader; /* threadgroup leader */ /* PID/PID hash table linkage. */ struct pid_link pids[PIDTYPE_MAX]; struct list_head thread_group; struct completion *vfork_done; /* for vfork() */ int __user *set_child_tid; /* CLONE_CHILD_SETTID */ int __user *clear_child_tid; /* CLONE_CHILD_CLEARTID */ unsigned long rt_priority; cputime_t utime, stime; unsigned long nvcsw, nivcsw; /* context switch counts */ struct timespec start_time; /* mm fault and swap info: this can arguably be seen as either mm-specific or thread-specific */ unsigned long min_flt, maj_flt; cputime_t it_prof_expires, it_virt_expires; unsigned long long it_sched_expires; struct list_head cpu_timers[3]; /* process credentials */ uid_t uid,euid,suid,fsuid; gid_t gid,egid,sgid,fsgid; struct group_info *group_info; kernel_cap_t cap_effective, cap_inheritable, cap_permitted; unsigned keep_capabilities:1; struct user_struct *user; #ifdef CONFIG_KEYS struct key *request_key_auth; /* assumed request_key authority */ struct key *thread_keyring; /* keyring private to this thread */ unsigned char jit_keyring; /* default keyring to attach requested keys to */ #endif int oomkilladj; /* OOM kill score adjustment (bit shift). */ char comm[TASK_COMM_LEN]; /* executable name excluding path - access with [gs]et_task_comm (which lock it with task_lock()) - initialized normally by flush_old_exec */ /* file system info */ int link_count, total_link_count; /* ipc stuff */ struct sysv_sem sysvsem; /* CPU-specific state of this task */ struct thread_struct thread; /* filesystem information */ struct fs_struct *fs; /* open file information */ struct files_struct *files; /* namespace */ struct namespace *namespace; /* signal handlers */ struct signal_struct *signal; struct sighand_struct *sighand; sigset_t blocked, real_blocked; sigset_t saved_sigmask; /* To be restored with TIF_RESTORE_SIGMASK */ struct sigpending pending; unsigned long sas_ss_sp; size_t sas_ss_size; int (*notifier)(void *priv); void *notifier_data; sigset_t *notifier_mask; void *security; struct audit_context *audit_context; seccomp_t seccomp; /* Thread group tracking */ u32 parent_exec_id; u32 self_exec_id; /* Protection of (de-)allocation: mm, files, fs, tty, keyrings */ spinlock_t alloc_lock; /* Protection of proc_dentry: nesting proc_lock, dcache_lock, write_lock_irq(&tasklist_lock); */ spinlock_t proc_lock; #ifdef CONFIG_DEBUG_MUTEXES /* mutex deadlock detection */ struct mutex_waiter *blocked_on; #endif /* journalling filesystem info */ void *journal_info; /* VM state */ struct reclaim_state *reclaim_state; struct dentry *proc_dentry; struct backing_dev_info *backing_dev_info; struct io_context *io_context; unsigned long ptrace_message; siginfo_t *last_siginfo; /* For ptrace use. */ /* * current io wait handle: wait queue entry to use for io waits * If this thread is processing aio, this points at the waitqueue * inside the currently handled kiocb. It may be NULL (i.e. default * to a stack based synchronous wait) if its doing sync IO. */ wait_queue_t *io_wait; /* i/o counters(bytes read/written, #syscalls */ u64 rchar, wchar, syscr, syscw; #if defined(CONFIG_BSD_PROCESS_ACCT) u64 acct_rss_mem1; /* accumulated rss usage */ u64 acct_vm_mem1; /* accumulated virtual memory usage */ clock_t acct_stimexpd; /* clock_t-converted stime since last update */ #endif #ifdef CONFIG_NUMA struct mempolicy *mempolicy; short il_next; #endif #ifdef CONFIG_CPUSETS struct cpuset *cpuset; nodemask_t mems_allowed; int cpuset_mems_generation; int cpuset_mem_spread_rotor; #endif struct robust_list_head __user *robust_list; #ifdef CONFIG_COMPAT struct compat_robust_list_head __user *compat_robust_list; #endif atomic_t fs_excl; /* holding fs exclusive resources */ struct rcu_head rcu; /* * cache last used pipe for splice */ struct pipe_inode_info *splice_pipe; };

struct task_struct 是 Linux kernel 表示 task 的標準資料結構。sys_getpid 傳回 current->tgid 即完成工作，其中 tgid 表示 thread group ID 即 PID。

--作者／陳俊宏 (www.jollen.org)

]]> https://www.jollen.org/blog/2006/10/linux_system_calls_forum_120_s.html https://www.jollen.org/blog/2006/10/linux_system_calls_forum_120_s.html Linux Device Drivers & Kernel Wed, 11 Oct 2006 17:01:32 +0800 no Syscall name Implementation file in Linux 2.6.11 (or above)

目前大致把 Linux 2.6.11 的 system call 分成以下幾個類別：

• Machine-dependent (i386)

• Filesystem

• Linux kernel

• Scheduling

• Signals

• Systems

• Time

• Kernel Timer & Process

• 16-bit uid

• Memory Management

• Swapfile

• Socket

最後一個欄位列出該 system call 實作的檔案 (以 Linux 2.6.11 為主)。請注意，Blog 裡並沒有該檔案的 hyperlink，您可以複制本 blog，並準備一份 Linux 2.6.11 (or above) 的原始碼，以方便 link 到檔案做查詢。 Machine-dependent (i386) 101 sys_ioperm linux/arch/i386/kernel/ioport.c 110 sys_iopl linux/arch/i386/kernel/ioport.c 123 sys_modify_ldt linux/arch/i386/kernel/ldt.c 2 sys_fork linux/arch/i386/kernel/process.c 11 sys_execve linux/arch/i386/kernel/process.c 120 sys_clone linux/arch/i386/kernel/process.c 190 sys_vfork linux/arch/i386/kernel/process.c 243 sys_set_thread_area linux/arch/i386/kernel/process.c 244 sys_get_thread_area linux/arch/i386/kernel/process.c 26 sys_ptrace linux/arch/i386/kernel/ptrace.c 67 sys_sigaction linux/arch/i386/kernel/signal.c 72 sys_sigsuspend linux/arch/i386/kernel/signal.c 119 sys_sigreturn linux/arch/i386/kernel/signal.c 173 sys_rt_sigreturn linux/arch/i386/kernel/signal.c 179 sys_rt_sigsuspend linux/arch/i386/kernel/signal.c 186 sys_sigaltstack linux/arch/i386/kernel/signal.c 42 sys_pipe linux/arch/i386/kernel/sys_i386.c 59 sys_olduname linux/arch/i386/kernel/sys_i386.c 82 old_select linux/arch/i386/kernel/sys_i386.c 90 old_mmap linux/arch/i386/kernel/sys_i386.c 109 sys_uname linux/arch/i386/kernel/sys_i386.c 117 sys_ipc linux/arch/i386/kernel/sys_i386.c 192 sys_mmap2 linux/arch/i386/kernel/sys_i386.c 113 sys_vm86old linux/arch/i386/kernel/vm86.c 166 sys_vm86 linux/arch/i386/kernel/vm86.c Filesystem 245 sys_io_setup linux/fs/aio.c 246 sys_io_destroy linux/fs/aio.c 247 sys_io_getevents linux/fs/aio.c 248 sys_io_submit linux/fs/aio.c 249 sys_io_cancel linux/fs/aio.c 36 sys_sync linux/fs/buffer.c 118 sys_fsync linux/fs/buffer.c 134 sys_bdflush linux/fs/buffer.c 148 sys_fdatasync linux/fs/buffer.c 183 sys_getcwd linux/fs/dcache.c 253 sys_lookup_dcookie linux/fs/dcookies.c 254 sys_epoll_create linux/fs/eventpoll.c 255 sys_epoll_ctl linux/fs/eventpoll.c 256 sys_epoll_wait linux/fs/eventpoll.c 86 sys_uselib linux/fs/exec.c 41 sys_dup linux/fs/fcntl.c 55 sys_fcntl linux/fs/fcntl.c 63 sys_dup2 linux/fs/fcntl.c 221 sys_fcntl64 linux/fs/fcntl.c 135 sys_sysfs linux/fs/filesystems.c 54 sys_ioctl linux/fs/ioctl.c 143 sys_flock linux/fs/locks.c 9 sys_link linux/fs/namei.c 10 sys_unlink linux/fs/namei.c 14 sys_mknod linux/fs/namei.c 38 sys_rename linux/fs/namei.c 39 sys_mkdir linux/fs/namei.c 40 sys_rmdir linux/fs/namei.c 83 sys_symlink linux/fs/namei.c 21 sys_mount linux/fs/namespace.c 22 sys_oldumount linux/fs/namespace.c 52 sys_umount linux/fs/namespace.c 217 sys_pivot_root linux/fs/namespace.c 169 sys_nfsservctl linux/fs/nfsctl.c 5 sys_open linux/fs/open.c 6 sys_close linux/fs/open.c 8 sys_creat linux/fs/open.c 12 sys_chdir linux/fs/open.c 15 sys_chmod linux/fs/open.c 30 sys_utime linux/fs/open.c 33 sys_access linux/fs/open.c 61 sys_chroot linux/fs/open.c 92 sys_truncate linux/fs/open.c 93 sys_ftruncate linux/fs/open.c 94 sys_fchmod linux/fs/open.c 99 sys_statfs linux/fs/open.c 100 sys_fstatfs linux/fs/open.c 111 sys_vhangup linux/fs/open.c 133 sys_fchdir linux/fs/open.c 193 sys_truncate64 linux/fs/open.c 194 sys_ftruncate64 linux/fs/open.c 198 sys_lchown linux/fs/open.c 207 sys_fchown linux/fs/open.c 212 sys_chown linux/fs/open.c 268 sys_statfs64 linux/fs/open.c 269 sys_fstatfs64 linux/fs/open.c 131 sys_quotactl linux/fs/quota.c 89 old_readdir linux/fs/readdir.c 141 sys_getdents linux/fs/readdir.c 220 sys_getdents64 linux/fs/readdir.c 3 sys_read linux/fs/read_write.c 4 sys_write linux/fs/read_write.c 19 sys_lseek linux/fs/read_write.c 140 sys_llseek linux/fs/read_write.c 145 sys_readv linux/fs/read_write.c 146 sys_writev linux/fs/read_write.c 180 sys_pread64 linux/fs/read_write.c 181 sys_pwrite64 linux/fs/read_write.c 187 sys_sendfile linux/fs/read_write.c 239 sys_sendfile64 linux/fs/read_write.c 142 sys_select linux/fs/select.c 168 sys_poll linux/fs/select.c 18 sys_stat linux/fs/stat.c 28 sys_fstat linux/fs/stat.c 84 sys_lstat linux/fs/stat.c 85 sys_readlink linux/fs/stat.c 106 sys_newstat linux/fs/stat.c 107 sys_newlstat linux/fs/stat.c 108 sys_newfstat linux/fs/stat.c 195 sys_stat64 linux/fs/stat.c 196 sys_lstat64 linux/fs/stat.c 197 sys_fstat64 linux/fs/stat.c 62 sys_ustat linux/fs/super.c 226 sys_setxattr linux/fs/xattr.c 227 sys_lsetxattr linux/fs/xattr.c 228 sys_fsetxattr linux/fs/xattr.c 229 sys_getxattr linux/fs/xattr.c 230 sys_lgetxattr linux/fs/xattr.c 231 sys_fgetxattr linux/fs/xattr.c 232 sys_listxattr linux/fs/xattr.c 233 sys_llistxattr linux/fs/xattr.c 234 sys_flistxattr linux/fs/xattr.c 235 sys_removexattr linux/fs/xattr.c 236 sys_lremovexattr linux/fs/xattr.c 237 sys_fremovexattr linux/fs/xattr.c Linux Kernel 51 sys_acct linux/kernel/acct.c 184 sys_capget linux/kernel/capability.c 185 sys_capset linux/kernel/capability.c 136 sys_personality linux/kernel/exec_domain.c 1 sys_exit linux/kernel/exit.c 7 sys_waitpid linux/kernel/exit.c 114 sys_wait4 linux/kernel/exit.c 252 sys_exit_group linux/kernel/exit.c 258 sys_set_tid_address linux/kernel/fork.c 240 sys_futex linux/kernel/futex.c 104 sys_setitimer linux/kernel/itimer.c 105 sys_getitimer linux/kernel/itimer.c 128 sys_init_module linux/kernel/module.c 129 sys_delete_module linux/kernel/module.c 162 sys_nanosleep linux/kernel/posix-timers.c 259 sys_timer_create linux/kernel/posix-timers.c 260 sys_timer_settime linux/kernel/posix-timers.c 261 sys_timer_gettime linux/kernel/posix-timers.c 262 sys_timer_getoverrun linux/kernel/posix-timers.c 263 sys_timer_delete linux/kernel/posix-timers.c 264 sys_clock_settime linux/kernel/posix-timers.c 265 sys_clock_gettime linux/kernel/posix-timers.c 266 sys_clock_getres linux/kernel/posix-timers.c 267 sys_clock_nanosleep linux/kernel/posix-timers.c 103 sys_syslog linux/kernel/printk.c Scheduling 34 sys_nice linux/kernel/sched.c 154 sys_sched_setparam linux/kernel/sched.c 155 sys_sched_getparam linux/kernel/sched.c 156 sys_sched_setscheduler linux/kernel/sched.c 157 sys_sched_getscheduler linux/kernel/sched.c 158 sys_sched_yield linux/kernel/sched.c 159 sys_sched_get_priority_max linux/kernel/sched.c 160 sys_sched_get_priority_min linux/kernel/sched.c 161 sys_sched_rr_get_interval linux/kernel/sched.c 241 sys_sched_setaffinity linux/kernel/sched.c 242 sys_sched_getaffinity linux/kernel/sched.c Signals 0 sys_restart_syscall linux/kernel/signal.c 29 sys_pause linux/kernel/signal.c 37 sys_kill linux/kernel/signal.c 48 sys_signal linux/kernel/signal.c 68 sys_sgetmask linux/kernel/signal.c 69 sys_ssetmask linux/kernel/signal.c 73 sys_sigpending linux/kernel/signal.c 126 sys_sigprocmask linux/kernel/signal.c 174 sys_rt_sigaction linux/kernel/signal.c 175 sys_rt_sigprocmask linux/kernel/signal.c 176 sys_rt_sigpending linux/kernel/signal.c 177 sys_rt_sigtimedwait linux/kernel/signal.c 178 sys_rt_sigqueueinfo linux/kernel/signal.c 238 sys_tkill linux/kernel/signal.c 270 sys_tgkill linux/kernel/signal.c Systems 43 sys_times linux/kernel/sys.c 57 sys_setpgid linux/kernel/sys.c 60 sys_umask linux/kernel/sys.c 65 sys_getpgrp linux/kernel/sys.c 66 sys_setsid linux/kernel/sys.c 74 sys_sethostname linux/kernel/sys.c 75 sys_setrlimit linux/kernel/sys.c 76 sys_old_getrlimit linux/kernel/sys.c 77 sys_getrusage linux/kernel/sys.c 88 sys_reboot linux/kernel/sys.c 96 sys_getpriority linux/kernel/sys.c 97 sys_setpriority linux/kernel/sys.c 121 sys_setdomainname linux/kernel/sys.c 122 sys_newuname linux/kernel/sys.c 132 sys_getpgid linux/kernel/sys.c 147 sys_getsid linux/kernel/sys.c 172 sys_prctl linux/kernel/sys.c 191 sys_getrlimit linux/kernel/sys.c 203 sys_setreuid linux/kernel/sys.c 204 sys_setregid linux/kernel/sys.c 205 sys_getgroups linux/kernel/sys.c 206 sys_setgroups linux/kernel/sys.c 208 sys_setresuid linux/kernel/sys.c 209 sys_getresuid linux/kernel/sys.c 210 sys_setresgid linux/kernel/sys.c 211 sys_getresgid linux/kernel/sys.c 213 sys_setuid linux/kernel/sys.c 214 sys_setgid linux/kernel/sys.c 215 sys_setfsuid linux/kernel/sys.c 216 sys_setfsgid linux/kernel/sys.c 149 sys_sysctl linux/kernel/sysctl.c Time 13 sys_time linux/kernel/time.c 25 sys_stime linux/kernel/time.c 78 sys_gettimeofday linux/kernel/time.c 79 sys_settimeofday linux/kernel/time.c 124 sys_adjtimex linux/kernel/time.c Kernel Timer & Process 20 sys_getpid linux/kernel/timer.c 27 sys_alarm linux/kernel/timer.c 64 sys_getppid linux/kernel/timer.c 116 sys_sysinfo linux/kernel/timer.c 199 sys_getuid linux/kernel/timer.c 200 sys_getgid linux/kernel/timer.c 201 sys_geteuid linux/kernel/timer.c 202 sys_getegid linux/kernel/timer.c 224 sys_gettid linux/kernel/timer.c 16-bit uid (wrapper functions) 16 sys_lchown16 linux/kernel/uid16.c 23 sys_setuid16 linux/kernel/uid16.c 24 sys_getuid16 linux/kernel/uid16.c 46 sys_setgid16 linux/kernel/uid16.c 47 sys_getgid16 linux/kernel/uid16.c 49 sys_geteuid16 linux/kernel/uid16.c 50 sys_getegid16 linux/kernel/uid16.c 70 sys_setreuid16 linux/kernel/uid16.c 71 sys_setregid16 linux/kernel/uid16.c 80 sys_getgroups16 linux/kernel/uid16.c 81 sys_setgroups16 linux/kernel/uid16.c 95 sys_fchown16 linux/kernel/uid16.c 138 sys_setfsuid16 linux/kernel/uid16.c 139 sys_setfsgid16 linux/kernel/uid16.c 164 sys_setresuid16 linux/kernel/uid16.c 165 sys_getresuid16 linux/kernel/uid16.c 170 sys_setresgid16 linux/kernel/uid16.c 171 sys_getresgid16 linux/kernel/uid16.c 182 sys_chown16 linux/kernel/uid16.c Memory Management 250 sys_fadvise64 linux/mm/fadvise.c 225 sys_readahead linux/mm/filemap.c 257 sys_remap_file_pages linux/mm/fremap.c 219 sys_madvise linux/mm/madvise.c 218 sys_mincore linux/mm/mincore.c 150 sys_mlock linux/mm/mlock.c 151 sys_munlock linux/mm/mlock.c 152 sys_mlockall linux/mm/mlock.c 153 sys_munlockall linux/mm/mlock.c 45 sys_brk linux/mm/mmap.c 91 sys_munmap linux/mm/mmap.c 125 sys_mprotect linux/mm/mprotect.c 163 sys_mremap linux/mm/mremap.c 144 sys_msync linux/mm/msync.c Swapfile 87 sys_swapon linux/mm/swapfile.c 115 sys_swapoff linux/mm/swapfile.c Socket 102 sys_socketcall linux/net/socket.c ]]> https://www.jollen.org/blog/2006/10/linux_26_system_call12.html https://www.jollen.org/blog/2006/10/linux_26_system_call12.html Linux Device Drivers & Kernel Wed, 11 Oct 2006 14:58:32 +0800 Linux (kernel 2.6.11) System Call Table 1. sys_ni_syscall 為保留號碼 2. 更新日期: 2006/10/07 3. 第一次發佈 2.6 kernel 的 LSCT

no	Syscall	Prototype decl.
0	sys_restart_syscall	long sys_restart_syscall(void)
1	sys_exit	long sys_exit(int error_code)
2	sys_fork	int sys_fork(struct pt_regs regs)
3	sys_read	ssize_t sys_read(unsigned int fd, char __user * buf, size_t count)
4	sys_write	ssize_t sys_write(unsigned int fd, const char __user * buf, size_t count)
5	sys_open	long sys_open(const char __user * filename, int flags, int mode)
6	sys_close	long sys_close(unsigned int fd)
7	sys_waitpid	long sys_waitpid(pid_t pid, int __user * stat_addr, int options)
8	sys_creat	long sys_creat(const char __user * pathname, int mode)
9	sys_link	long sys_link(const char __user * oldname, const char __user * newname)
10	sys_unlink	long sys_unlink(const char __user * pathname)
11	sys_execve	int sys_execve(struct pt_regs regs)
12	sys_chdir	long sys_chdir(const char __user * filename)
13	sys_time	long sys_time(time_t __user * tloc)
14	sys_mknod	long sys_mknod(const char __user * filename, int mode, unsigned dev)
15	sys_chmod	long sys_chmod(const char __user * filename, mode_t mode)
16	sys_lchown16	long sys_lchown16(const char __user * filename, old_uid_t user, old_gid_t group)
17	sys_ni_syscall	long sys_ni_syscall(void)
18	sys_stat	long sys_stat(char __user * filename, struct __old_kernel_stat __user * statbuf)
19	sys_lseek	off_t sys_lseek(unsigned int fd, off_t offset, unsigned int origin)
20	sys_getpid	long sys_getpid(void)
21	sys_mount	long sys_mount(char __user * dev_name, char __user * dir_name, char __user * type, unsigned long flags, void __user * data)
22	sys_oldumount	long sys_oldumount(char __user * name)
23	sys_setuid16	long sys_setuid16(old_uid_t uid)
24	sys_getuid16	long sys_getuid16(void)
25	sys_stime	long sys_stime(time_t __user * tptr)
26	sys_ptrace	int sys_ptrace(long request, long pid, long addr, long data)
27	sys_alarm	unsigned long sys_alarm(unsigned int seconds)
28	sys_fstat	long sys_fstat(unsigned int fd, struct __old_kernel_stat __user * statbuf)
29	sys_pause	long sys_pause(void)
30	sys_utime	long sys_utime(char __user * filename, struct utimbuf __user * times)
31	sys_ni_syscall	long sys_ni_syscall(void)
32	sys_ni_syscall	long sys_ni_syscall(void)
33	sys_access	long sys_access(const char __user * filename, int mode)
34	sys_nice	long sys_nice(int increment)
35	sys_ni_syscall	long sys_ni_syscall(void)
36	sys_sync	long sys_sync(void)
37	sys_kill	long sys_kill(int pid, int sig)
38	sys_rename	long sys_rename(const char __user * oldname, const char __user * newname)
39	sys_mkdir	long sys_mkdir(const char __user * pathname, int mode)
40	sys_rmdir	long sys_rmdir(const char __user * pathname)
41	sys_dup	long sys_dup(unsigned int fildes)
42	sys_pipe	int sys_pipe(unsigned long __user * fildes)
43	sys_times	long sys_times(struct tms __user * tbuf)
44	sys_ni_syscall	long sys_ni_syscall(void)
45	sys_brk	unsigned long sys_brk(unsigned long brk)
46	sys_setgid16	long sys_setgid16(old_gid_t gid)
47	sys_getgid16	long sys_getgid16(void)
48	sys_signal	unsigned long sys_signal(int sig, __sighandler_t handler)
49	sys_geteuid16	long sys_geteuid16(void)
50	sys_getegid16	long sys_getegid16(void)
51	sys_acct	long sys_acct(const char __user * name)
52	sys_umount	long sys_umount(char __user * name, int flags)
53	sys_ni_syscall	long sys_ni_syscall(void)
54	sys_ioctl	long sys_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg)
55	sys_fcntl	long sys_fcntl(unsigned int fd, unsigned int cmd, unsigned long arg)
56	sys_ni_syscall	long sys_ni_syscall(void)
57	sys_setpgid	long sys_setpgid(pid_t pid, pid_t pgid)
58	sys_ni_syscall	long sys_ni_syscall(void)
59	sys_olduname	int sys_olduname(struct oldold_utsname __user * name)
60	sys_umask	long sys_umask(int mask)
61	sys_chroot	long sys_chroot(const char __user * filename)
62	sys_ustat	long sys_ustat(unsigned dev, struct ustat __user * ubuf)
63	sys_dup2	long sys_dup2(unsigned int oldfd, unsigned int newfd)
64	sys_getppid	long sys_getppid(void)
65	sys_getpgrp	long sys_getpgrp(void)
66	sys_setsid	long sys_setsid(void)
67	sys_sigaction	int sys_sigaction(int sig, const struct old_sigaction __user * act, struct old_sigaction __user * oact)
68	sys_sgetmask	long sys_sgetmask(void)
69	sys_ssetmask	long sys_ssetmask(int newmask)
70	sys_setreuid16	long sys_setreuid16(old_uid_t ruid, old_uid_t euid)
71	sys_setregid16	long sys_setregid16(old_gid_t rgid, old_gid_t egid)
72	sys_sigsuspend	int sys_sigsuspend(int history0, int history1, old_sigset_t mask)
73	sys_sigpending	long sys_sigpending(old_sigset_t __user * set)
74	sys_sethostname	long sys_sethostname(char __user * name, int len)
75	sys_setrlimit	long sys_setrlimit(unsigned int resource, struct rlimit __user * rlim)
76	sys_old_getrlimit	long sys_old_getrlimit(unsigned int resource, struct rlimit __user * rlim)
77	sys_getrusage	long sys_getrusage(int who, struct rusage __user * ru)
78	sys_gettimeofday	long sys_gettimeofday(struct timeval __user * tv, struct timezone __user * tz)
79	sys_settimeofday	long sys_settimeofday(struct timeval __user * tv, struct timezone __user * tz)
80	sys_getgroups16	long sys_getgroups16(int gidsetsize, old_gid_t __user * grouplist)
81	sys_setgroups16	long sys_setgroups16(int gidsetsize, old_gid_t __user * grouplist)
82	old_select	int old_select(struct sel_arg_struct __user * arg)
83	sys_symlink	long sys_symlink(const char __user * oldname, const char __user * newname)
84	sys_lstat	long sys_lstat(char __user * filename, struct __old_kernel_stat __user * statbuf)
85	sys_readlink	long sys_readlink(const char __user * path, char __user * buf, int bufsiz)
86	sys_uselib	long sys_uselib(const char __user * library)
87	sys_swapon	long sys_swapon(const char __user * specialfile, int swap_flags)
88	sys_reboot	long sys_reboot(int magic1, int magic2, unsigned int cmd, void __user * arg)
89	old_readdir	long old_readdir(unsigned int fd, struct old_linux_dirent __user * dirent, unsigned int count)
90	old_mmap	int old_mmap(struct mmap_arg_struct __user * arg)
91	sys_munmap	long sys_munmap(unsigned long addr, size_t len)
92	sys_truncate	long sys_truncate(const char __user * path, unsigned long length)
93	sys_ftruncate	long sys_ftruncate(unsigned int fd, unsigned long length)
94	sys_fchmod	long sys_fchmod(unsigned int fd, mode_t mode)
95	sys_fchown16	long sys_fchown16(unsigned int fd, old_uid_t user, old_gid_t group)
96	sys_getpriority	long sys_getpriority(int which, int who)
97	sys_setpriority	long sys_setpriority(int which, int who, int niceval)
98	sys_ni_syscall	long sys_ni_syscall(void)
99	sys_statfs	long sys_statfs(const char __user * path, struct statfs __user * buf)
100	sys_fstatfs	long sys_fstatfs(unsigned int fd, struct statfs __user * buf)
101	sys_ioperm	long sys_ioperm(unsigned long from, unsigned long num, int turn_on)
102	sys_socketcall	long sys_socketcall(int call, unsigned long __user * args)
103	sys_syslog	long sys_syslog(int type, char __user * buf, int len)
104	sys_setitimer	long sys_setitimer(int which, struct itimerval __user * value, struct itimerval __user * ovalue)
105	sys_getitimer	long sys_getitimer(int which, struct itimerval __user * value)
106	sys_newstat	long sys_newstat(char __user * filename, struct stat __user * statbuf)
107	sys_newlstat	long sys_newlstat(char __user * filename, struct stat __user * statbuf)
108	sys_newfstat	long sys_newfstat(unsigned int fd, struct stat __user * statbuf)
109	sys_uname	int sys_uname(struct old_utsname __user * name)
110	sys_iopl	long sys_iopl(unsigned long unused)
111	sys_vhangup	long sys_vhangup(void)
112	sys_ni_syscall	long sys_ni_syscall(void)
113	sys_vm86old	int sys_vm86old(struct pt_regs regs)
114	sys_wait4	long sys_wait4(pid_t pid, int __user * stat_addr, int options, struct rusage __user * ru)
115	sys_swapoff	long sys_swapoff(const char __user * specialfile)
116	sys_sysinfo	long sys_sysinfo(struct sysinfo __user * info)
117	sys_ipc	int sys_ipc(uint call, int first, int second, int third, void __user * ptr, long fifth)
118	sys_fsync	long sys_fsync(unsigned int fd)
119	sys_sigreturn	int sys_sigreturn(unsigned long __unused)
120	sys_clone	int sys_clone(struct pt_regs regs)
121	sys_setdomainname	long sys_setdomainname(char __user * name, int len)
122	sys_newuname	long sys_newuname(struct new_utsname __user * name)
123	sys_modify_ldt	int sys_modify_ldt(int func, void __user * ptr, unsigned long bytecount)
124	sys_adjtimex	long sys_adjtimex(struct timex __user * txc_p)
125	sys_mprotect	long sys_mprotect(unsigned long start, size_t len, unsigned long prot)
126	sys_sigprocmask	long sys_sigprocmask(int how, old_sigset_t __user * set, old_sigset_t __user * oset)
127	sys_ni_syscall	long sys_ni_syscall(void)
128	sys_init_module	long sys_init_module(void __user * umod, unsigned long len, const char __user * uargs)
129	sys_delete_module	long sys_delete_module(const char __user * name_user, unsigned int flags)
130	sys_ni_syscall	long sys_ni_syscall(void)
131	sys_quotactl	long sys_quotactl(unsigned int cmd, const char __user * special, qid_t id, void __user * addr)
132	sys_getpgid	long sys_getpgid(pid_t pid)
133	sys_fchdir	long sys_fchdir(unsigned int fd)
134	sys_bdflush	long sys_bdflush(int func, long data)
135	sys_sysfs	long sys_sysfs(int option, unsigned long arg1, unsigned long arg2)
136	sys_personality	long sys_personality(u_long personality)
137	sys_ni_syscall	long sys_ni_syscall(void)
138	sys_setfsuid16	long sys_setfsuid16(old_uid_t uid)
139	sys_setfsgid16	long sys_setfsgid16(old_gid_t gid)
140	sys_llseek	long sys_llseek(unsigned int fd, unsigned long offset_high, unsigned long offset_low, loff_t __user * result, unsigned int origin)
141	sys_getdents	long sys_getdents(unsigned int fd, struct linux_dirent __user * dirent, unsigned int count)
142	sys_select	long sys_select(int n, fd_set __user * inp, fd_set __user * outp, fd_set __user * exp, struct timeval __user * tvp)
143	sys_flock	long sys_flock(unsigned int fd, unsigned int cmd)
144	sys_msync	long sys_msync(unsigned long start, size_t len, int flags)
145	sys_readv	ssize_t sys_readv(unsigned long fd, const struct iovec __user * vec, unsigned long vlen)
146	sys_writev	ssize_t sys_writev(unsigned long fd, const struct iovec __user * vec, unsigned long vlen)
147	sys_getsid	long sys_getsid(pid_t pid)
148	sys_fdatasync	long sys_fdatasync(unsigned int fd)
149	sys_sysctl	long sys_sysctl(struct __sysctl_args __user * args)
150	sys_mlock	long sys_mlock(unsigned long start, size_t len)
151	sys_munlock	long sys_munlock(unsigned long start, size_t len)
152	sys_mlockall	long sys_mlockall(int flags)
153	sys_munlockall	long sys_munlockall(void)
154	sys_sched_setparam	long sys_sched_setparam(pid_t pid, struct sched_param __user * param)
155	sys_sched_getparam	long sys_sched_getparam(pid_t pid, struct sched_param __user * param)
156	sys_sched_setscheduler	long sys_sched_setscheduler(pid_t pid, int policy, struct sched_param __user * param)
157	sys_sched_getscheduler	long sys_sched_getscheduler(pid_t pid)
158	sys_sched_yield	long sys_sched_yield(void)
159	sys_sched_get_priority_max	long sys_sched_get_priority_max(int policy)
160	sys_sched_get_priority_min	long sys_sched_get_priority_min(int policy)
161	sys_sched_rr_get_interval	long sys_sched_rr_get_interval(pid_t pid, struct timespec __user * interval)
162	sys_nanosleep	long sys_nanosleep(struct timespec __user * rqtp, struct timespec __user * rmtp)
163	sys_mremap	unsigned long sys_mremap(unsigned long addr, unsigned long old_len, unsigned long new_len, unsigned long flags, unsigned long new_addr)
164	sys_setresuid16	long sys_setresuid16(old_uid_t ruid, old_uid_t euid, old_uid_t suid)
165	sys_getresuid16	long sys_getresuid16(old_uid_t __user * ruid, old_uid_t __user * euid, old_uid_t __user * suid)
166	sys_vm86	int sys_vm86(struct pt_regs regs)
167	sys_ni_syscall	long sys_ni_syscall(void)
168	sys_poll	long sys_poll(struct pollfd __user * ufds, unsigned int nfds, long timeout)
169	sys_nfsservctl
170	sys_setresgid16	long sys_setresgid16(old_gid_t rgid, old_gid_t egid, old_gid_t sgid)
171	sys_getresgid16	long sys_getresgid16(old_gid_t __user * rgid, old_gid_t __user * egid, old_gid_t __user * sgid)
172	sys_prctl	long sys_prctl(int option, unsigned long arg2, unsigned long arg3, unsigned long arg4, unsigned long arg5)
173	sys_rt_sigreturn	int sys_rt_sigreturn(unsigned long __unused)
174	sys_rt_sigaction	long sys_rt_sigaction(int sig, const struct sigaction __user * act, struct sigaction __user * oact, size_t sigsetsize)
175	sys_rt_sigprocmask	long sys_rt_sigprocmask(int how, sigset_t __user * set, sigset_t __user * oset, size_t sigsetsize)
176	sys_rt_sigpending	long sys_rt_sigpending(sigset_t __user * set, size_t sigsetsize)
177	sys_rt_sigtimedwait	long sys_rt_sigtimedwait(const sigset_t __user * uthese, siginfo_t __user * uinfo, const struct timespec __user * uts, size_t sigsetsize)
178	sys_rt_sigqueueinfo	long sys_rt_sigqueueinfo(int pid, int sig, siginfo_t __user * uinfo)
179	sys_rt_sigsuspend	int sys_rt_sigsuspend(struct pt_regs regs)
180	sys_pread64	ssize_t sys_pread64(unsigned int fd, char __user * buf, size_t count, loff_t pos)
181	sys_pwrite64	ssize_t sys_pwrite64(unsigned int fd, const char __user * buf, size_t count, loff_t pos)
182	sys_chown16	long sys_chown16(const char __user * filename, old_uid_t user, old_gid_t group)
183	sys_getcwd	long sys_getcwd(char __user * buf, unsigned long size)
184	sys_capget	long sys_capget(cap_user_header_t header, cap_user_data_t dataptr)
185	sys_capset	long sys_capset(cap_user_header_t header, const cap_user_data_t data)
186	sys_sigaltstack	int sys_sigaltstack(unsigned long ebx)
187	sys_sendfile	ssize_t sys_sendfile(int out_fd, int in_fd, off_t __user * offset, size_t count)
188	sys_ni_syscall	long sys_ni_syscall(void)
189	sys_ni_syscall	long sys_ni_syscall(void)
190	sys_vfork	int sys_vfork(struct pt_regs regs)
191	sys_getrlimit	long sys_getrlimit(unsigned int resource, struct rlimit __user * rlim)
192	sys_mmap2	long sys_mmap2(unsigned long addr, unsigned long len, unsigned long prot, unsigned long flags, unsigned long fd, unsigned long pgoff)
193	sys_truncate64	long sys_truncate64(const char __user * path, loff_t length)
194	sys_ftruncate64	long sys_ftruncate64(unsigned int fd, loff_t length)
195	sys_stat64	long sys_stat64(char __user * filename, struct stat64 __user * statbuf)
196	sys_lstat64	long sys_lstat64(char __user * filename, struct stat64 __user * statbuf)
197	sys_fstat64	long sys_fstat64(unsigned long fd, struct stat64 __user * statbuf)
198	sys_lchown	long sys_lchown(const char __user * filename, uid_t user, gid_t group)
199	sys_getuid	long sys_getuid(void)
200	sys_getgid	long sys_getgid(void)
201	sys_geteuid	long sys_geteuid(void)
202	sys_getegid	long sys_getegid(void)
203	sys_setreuid	long sys_setreuid(uid_t ruid, uid_t euid)
204	sys_setregid	long sys_setregid(gid_t rgid, gid_t egid)
205	sys_getgroups	long sys_getgroups(int gidsetsize, gid_t __user * grouplist)
206	sys_setgroups	long sys_setgroups(int gidsetsize, gid_t __user * grouplist)
207	sys_fchown	long sys_fchown(unsigned int fd, uid_t user, gid_t group)
208	sys_setresuid	long sys_setresuid(uid_t ruid, uid_t euid, uid_t suid)
209	sys_getresuid	long sys_getresuid(uid_t __user * ruid, uid_t __user * euid, uid_t __user * suid)
210	sys_setresgid	long sys_setresgid(gid_t rgid, gid_t egid, gid_t sgid)
211	sys_getresgid	long sys_getresgid(gid_t __user * rgid, gid_t __user * egid, gid_t __user * sgid)
212	sys_chown	long sys_chown(const char __user * filename, uid_t user, gid_t group)
213	sys_setuid	long sys_setuid(uid_t uid)
214	sys_setgid	long sys_setgid(gid_t gid)
215	sys_setfsuid	long sys_setfsuid(uid_t uid)
216	sys_setfsgid	long sys_setfsgid(gid_t gid)
217	sys_pivot_root	long sys_pivot_root(const char __user * new_root, const char __user * put_old)
218	sys_mincore	long sys_mincore(unsigned long start, size_t len, unsigned char __user * vec)
219	sys_madvise	long sys_madvise(unsigned long start, size_t len_in, int behavior)
220	sys_getdents64	long sys_getdents64(unsigned int fd, struct linux_dirent64 __user * dirent, unsigned int count)
221	sys_fcntl64	long sys_fcntl64(unsigned int fd, unsigned int cmd, unsigned long arg)
222	sys_ni_syscall	long sys_ni_syscall(void)
223	sys_ni_syscall	long sys_ni_syscall(void)
224	sys_gettid	long sys_gettid(void)
225	sys_readahead	ssize_t sys_readahead(int fd, loff_t offset, size_t count)
226	sys_setxattr	long sys_setxattr(char __user * path, char __user * name, void __user * value, size_t size, int flags)
227	sys_lsetxattr	long sys_lsetxattr(char __user * path, char __user * name, void __user * value, size_t size, int flags)
228	sys_fsetxattr	long sys_fsetxattr(int fd, char __user * name, void __user * value, size_t size, int flags)
229	sys_getxattr	ssize_t sys_getxattr(char __user * path, char __user * name, void __user * value, size_t size)
230	sys_lgetxattr	ssize_t sys_lgetxattr(char __user * path, char __user * name, void __user * value, size_t size)
231	sys_fgetxattr	ssize_t sys_fgetxattr(int fd, char __user * name, void __user * value, size_t size)
232	sys_listxattr	ssize_t sys_listxattr(char __user * path, char __user * list, size_t size)
233	sys_llistxattr	ssize_t sys_llistxattr(char __user * path, char __user * list, size_t size)
234	sys_flistxattr	ssize_t sys_flistxattr(int fd, char __user * list, size_t size)
235	sys_removexattr	long sys_removexattr(char __user * path, char __user * name)
236	sys_lremovexattr	long sys_lremovexattr(char __user * path, char __user * name)
237	sys_fremovexattr	long sys_fremovexattr(int fd, char __user * name)
238	sys_tkill	long sys_tkill(int pid, int sig)
239	sys_sendfile64	ssize_t sys_sendfile64(int out_fd, int in_fd, loff_t __user * offset, size_t count)
240	sys_futex	long sys_futex(u32 __user * uaddr, int op, int val, struct timespec __user * utime, u32 __user * uaddr2, int val3)
241	sys_sched_setaffinity	long sys_sched_setaffinity(pid_t pid, unsigned int len, unsigned long __user * user_mask_ptr)
242	sys_sched_getaffinity	long sys_sched_getaffinity(pid_t pid, unsigned int len, unsigned long __user * user_mask_ptr)
243	sys_set_thread_area	int sys_set_thread_area(struct user_desc __user * u_info)
244	sys_get_thread_area	int sys_get_thread_area(struct user_desc __user * u_info)
245	sys_io_setup	long sys_io_setup(unsigned nr_events, aio_context_t __user * ctxp)
246	sys_io_destroy	long sys_io_destroy(aio_context_t ctx)
247	sys_io_getevents	long sys_io_getevents(aio_context_t ctx_id, long min_nr, long nr, struct io_event __user * events, struct timespec __user * timeout)
248	sys_io_submit	long sys_io_submit(aio_context_t ctx_id, long nr, struct iocb __user * __user * iocbpp)
249	sys_io_cancel	long sys_io_cancel(aio_context_t ctx_id, struct iocb __user * iocb, struct io_event __user * result)
250	sys_fadvise64	long sys_fadvise64(int fd, loff_t offset, size_t len, int advice)
251	sys_ni_syscall	long sys_ni_syscall(void)
252	sys_exit_group	void sys_exit_group(int error_code)
253	sys_lookup_dcookie	long sys_lookup_dcookie(u64 cookie64, char __user * buf, size_t len)
254	sys_epoll_create	long sys_epoll_create(int size)
255	sys_epoll_ctl	long sys_epoll_ctl(int epfd, int op, int fd, struct epoll_event __user * event)
256	sys_epoll_wait	long sys_epoll_wait(int epfd, struct epoll_event __user * events, int maxevents, int timeout)
257	sys_remap_file_pages	long sys_remap_file_pages(unsigned long start, unsigned long size, unsigned long __prot, unsigned long pgoff, unsigned long flags)
258	sys_set_tid_address	long sys_set_tid_address(int __user * tidptr)
259	sys_timer_create	long sys_timer_create(clockid_t which_clock, struct sigevent __user * timer_event_spec, timer_t __user * created_timer_id)
260	sys_timer_settime	long sys_timer_settime(timer_t timer_id, int flags, const struct itimerspec __user * new_setting, struct itimerspec __user * old_setting)
261	sys_timer_gettime	long sys_timer_gettime(timer_t timer_id, struct itimerspec __user * setting)
262	sys_timer_getoverrun	long sys_timer_getoverrun(timer_t timer_id)
263	sys_timer_delete	long sys_timer_delete(timer_t timer_id)
264	sys_clock_settime	long sys_clock_settime(clockid_t which_clock, const struct timespec __user * tp)
265	sys_clock_gettime	long sys_clock_gettime(clockid_t which_clock, struct timespec __user * tp)
266	sys_clock_getres	long sys_clock_getres(clockid_t which_clock, struct timespec __user * tp)
267	sys_clock_nanosleep	long sys_clock_nanosleep(clockid_t which_clock, int flags, const struct timespec __user * rqtp, struct timespec __user * rmtp)
268	sys_statfs64	long sys_statfs64(const char __user * path, size_t sz, struct statfs64 __user * buf)
269	sys_fstatfs64	long sys_fstatfs64(unsigned int fd, size_t sz, struct statfs64 __user * buf)
270	sys_tgkill	long sys_tgkill(int tgid, int pid, int sig)
271	sys_utimes	long sys_utimes(char __user * filename, struct timeval __user * utimes)
272	sys_fadvise64_64	long sys_fadvise64_64(int fd, loff_t offset, loff_t len, int advice)
273	sys_ni_syscall	long sys_ni_syscall(void)
274	sys_mbind	long sys_mbind(unsigned long start, unsigned long len, unsigned long mode, unsigned long __user * nmask, unsigned long maxnode, unsigned flags)
275	sys_get_mempolicy	long sys_get_mempolicy(int __user * policy, unsigned long __user * nmask, unsigned long maxnode, unsigned long addr, unsigned long flags)
276	sys_set_mempolicy	long sys_set_mempolicy(int mode, unsigned long __user * nmask, unsigned long maxnode)
277	sys_mq_open	long sys_mq_open(const char __user * u_name, int oflag, mode_t mode, struct mq_attr __user * u_attr)
278	sys_mq_unlink	long sys_mq_unlink(const char __user * u_name)
279	sys_mq_timedsend	long sys_mq_timedsend(mqd_t mqdes, const char __user * u_msg_ptr, size_t msg_len, unsigned int msg_prio, const struct timespec __user * u_abs_timeout)
280	sys_mq_timedreceive	ssize_t sys_mq_timedreceive(mqd_t mqdes, char __user * u_msg_ptr, size_t msg_len, unsigned int __user * u_msg_prio, const struct timespec __user * u_abs_timeout)
281	sys_mq_notify	long sys_mq_notify(mqd_t mqdes, const struct sigevent __user * u_notification)
282	sys_mq_getsetattr	long sys_mq_getsetattr(mqd_t mqdes, const struct mq_attr __user * u_mqstat, struct mq_attr __user * u_omqstat)
283	sys_ni_syscall	long sys_ni_syscall(void)
284	sys_waitid	long sys_waitid(int which, pid_t pid, struct siginfo __user * infop, int options, struct rusage __user * ru)
285	sys_ni_syscall	long sys_ni_syscall(void)
286	sys_add_key	long sys_add_key(const char __user * _type, const char __user * _description, const void __user * _payload, size_t plen, key_serial_t ringid)
287	sys_request_key	long sys_request_key(const char __user * _type, const char __user * _description, const char __user * _callout_info, key_serial_t destringid)
288	sys_keyctl	long sys_keyctl(int option, unsigned long arg2, unsigned long arg3, unsigned long arg4, unsigned long arg5)

]]> https://www.jollen.org/blog/2006/10/linux_2611_system_calls_table.html https://www.jollen.org/blog/2006/10/linux_2611_system_calls_table.html Linux Device Drivers & Kernel Sat, 07 Oct 2006 23:41:39 +0800 Linux (kernel 2.4.29) System Call Table 1. sys_ni_syscall 為保留號碼 2. 更新日期: 2006/10/07 3. 其實與 linux 2.4.22 是相同的，因此亦可參考我們之前 (3 年前) 整理的 LSCT。

no	Syscall	Prototype decl.
0	sys_ni_syscall	long sys_ni_syscall(void)
1	sys_exit	long sys_exit(int error_code)
2	sys_fork	int sys_fork(struct pt_regs regs)
3	sys_read	ssize_t sys_read(unsigned int fd, char *buf, size_t count)
4	sys_write	ssize_t sys_write(unsigned int fd, const char *buf, size_t count)
5	sys_open	long sys_open(const char *filename, int flags, int mode)
6	sys_close	long sys_close(unsigned int fd)
7	sys_waitpid	long sys_waitpid(pid_t pid, unsigned int *stat_addr, int options)
8	sys_creat	long sys_creat(const char *pathname, int mode)
9	sys_link	long sys_link(const char *oldname, const char *newname)
10	sys_unlink	long sys_unlink(const char *pathname)
11	sys_execve	int sys_execve(struct pt_regs regs)
12	sys_chdir	long sys_chdir(const char *filename)
13	sys_time	long sys_time(int *tloc)
14	sys_mknod	long sys_mknod(const char *filename, int mode, dev_t dev)
15	sys_chmod	long sys_chmod(const char *filename, mode_t mode)
16	sys_lchown16	long sys_lchown16(const char *filename, old_uid_t user, old_gid_t group)
17	sys_ni_syscall	long sys_ni_syscall(void)
18	sys_stat	long sys_stat(char *filename, struct __old_kernel_stat *statbuf)
19	sys_lseek	off_t sys_lseek(unsigned int fd, off_t offset, unsigned int origin)
20	sys_getpid	long sys_getpid(void)
21	sys_mount	long sys_mount(char *dev_name, char *dir_name, char *type, unsigned long flags, void *data)
22	sys_oldumount	long sys_oldumount(char *name)
23	sys_setuid16	long sys_setuid16(old_uid_t uid)
24	sys_getuid16	long sys_getuid16(void)
25	sys_stime	long sys_stime(int *tptr)
26	sys_ptrace	int sys_ptrace(long request, long pid, long addr, long data)
27	sys_alarm	unsigned long sys_alarm(unsigned int seconds)
28	sys_fstat	long sys_fstat(unsigned int fd, struct __old_kernel_stat *statbuf)
29	sys_pause	int sys_pause(void)
30	sys_utime	long sys_utime(char *filename, struct utimbuf *times)
31	sys_ni_syscall	long sys_ni_syscall(void)
32	sys_ni_syscall	long sys_ni_syscall(void)
33	sys_access	long sys_access(const char *filename, int mode)
34	sys_nice	long sys_nice(int increment)
35	sys_ni_syscall	long sys_ni_syscall(void)
36	sys_sync	long sys_sync(void)
37	sys_kill	long sys_kill(int pid, int sig)
38	sys_rename	long sys_rename(const char *oldname, const char *newname)
39	sys_mkdir	long sys_mkdir(const char *pathname, int mode)
40	sys_rmdir	long sys_rmdir(const char *pathname)
41	sys_dup	long sys_dup(unsigned int fildes)
42	sys_pipe	int sys_pipe(unsigned long *fildes)
43	sys_times	long sys_times(struct tms *tbuf)
44	sys_ni_syscall	long sys_ni_syscall(void)
45	sys_brk	unsigned long sys_brk(unsigned long brk)
46	sys_setgid16	long sys_setgid16(old_gid_t gid)
47	sys_getgid16	long sys_getgid16(void)
48	sys_signal	unsigned long sys_signal(int sig, __sighandler_t handler)
49	sys_geteuid16	long sys_geteuid16(void)
50	sys_getegid16	long sys_getegid16(void)
51	sys_acct	long sys_acct(const char *name)
52	sys_umount	long sys_umount(char *name, int flags)
53	sys_ni_syscall	long sys_ni_syscall(void)
54	sys_ioctl	long sys_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg)
55	sys_fcntl	long sys_fcntl(unsigned int fd, unsigned int cmd, unsigned long arg)
56	sys_ni_syscall	long sys_ni_syscall(void)
57	sys_setpgid	long sys_setpgid(pid_t pid, pid_t pgid)
58	sys_ni_syscall	long sys_ni_syscall(void)
59	sys_olduname	int sys_olduname(struct oldold_utsname *name)
60	sys_umask	long sys_umask(int mask)
61	sys_chroot	long sys_chroot(const char *filename)
62	sys_ustat	long sys_ustat(dev_t dev, struct ustat *ubuf)
63	sys_dup2	long sys_dup2(unsigned int oldfd, unsigned int newfd)
64	sys_getppid	long sys_getppid(void)
65	sys_getpgrp	long sys_getpgrp(void)
66	sys_setsid	long sys_setsid(void)
67	sys_sigaction	int sys_sigaction(int sig, const struct old_sigaction *act, struct old_sigaction *oact)
68	sys_sgetmask	long sys_sgetmask(void)
69	sys_ssetmask	long sys_ssetmask(int newmask)
70	sys_setreuid16	long sys_setreuid16(old_uid_t ruid, old_uid_t euid)
71	sys_setregid16	long sys_setregid16(old_gid_t rgid, old_gid_t egid)
72	sys_sigsuspend	int sys_sigsuspend(int history0, int history1, old_sigset_t mask)
73	sys_sigpending	long sys_sigpending(old_sigset_t * set)
74	sys_sethostname	long sys_sethostname(char *name, int len)
75	sys_setrlimit	long sys_setrlimit(unsigned int resource, struct rlimit *rlim)
76	sys_old_getrlimit	long sys_old_getrlimit(unsigned int resource, struct rlimit *rlim)
77	sys_getrusage	long sys_getrusage(int who, struct rusage *ru)
78	sys_gettimeofday	long sys_gettimeofday(struct timeval *tv, struct timezone *tz)
79	sys_settimeofday	long sys_settimeofday(struct timeval *tv, struct timezone *tz)
80	sys_getgroups16	long sys_getgroups16(int gidsetsize, old_gid_t * grouplist)
81	sys_setgroups16	long sys_setgroups16(int gidsetsize, old_gid_t * grouplist)
82	old_select	int old_select(struct sel_arg_struct *arg)
83	sys_symlink	long sys_symlink(const char *oldname, const char *newname)
84	sys_lstat	long sys_lstat(char *filename, struct __old_kernel_stat *statbuf)
85	sys_readlink	long sys_readlink(const char *path, char *buf, int bufsiz)
86	sys_uselib	long sys_uselib(const char *library)
87	sys_swapon	long sys_swapon(const char *specialfile, int swap_flags)
88	sys_reboot	long sys_reboot(int magic1, int magic2, unsigned int cmd, void *arg)
89	old_readdir	int old_readdir(unsigned int fd, void *dirent, unsigned int count)
90	old_mmap	int old_mmap(struct mmap_arg_struct *arg)
91	sys_munmap	long sys_munmap(unsigned long addr, size_t len)
92	sys_truncate	long sys_truncate(const char *path, unsigned long length)
93	sys_ftruncate	long sys_ftruncate(unsigned int fd, unsigned long length)
94	sys_fchmod	long sys_fchmod(unsigned int fd, mode_t mode)
95	sys_fchown16	long sys_fchown16(unsigned int fd, old_uid_t user, old_gid_t group)
96	sys_getpriority	long sys_getpriority(int which, int who)
97	sys_setpriority	long sys_setpriority(int which, int who, int niceval)
98	sys_ni_syscall	long sys_ni_syscall(void)
99	sys_statfs	long sys_statfs(const char *path, struct statfs *buf)
100	sys_fstatfs	long sys_fstatfs(unsigned int fd, struct statfs *buf)
101	sys_ioperm	int sys_ioperm(unsigned long from, unsigned long num, int turn_on)
102	sys_socketcall	long sys_socketcall(int call, unsigned long *args)
103	sys_syslog	long sys_syslog(int type, char *buf, int len)
104	sys_setitimer	long sys_setitimer(int which, struct itimerval *value, struct itimerval *ovalue)
105	sys_getitimer	long sys_getitimer(int which, struct itimerval *value)
106	sys_newstat	long sys_newstat(char *filename, struct stat *statbuf)
107	sys_newlstat	long sys_newlstat(char *filename, struct stat *statbuf)
108	sys_newfstat	long sys_newfstat(unsigned int fd, struct stat *statbuf)
109	sys_uname	int sys_uname(struct old_utsname *name)
110	sys_iopl	int sys_iopl(unsigned long unused)
111	sys_vhangup	long sys_vhangup(void)
112	sys_ni_syscall	long sys_ni_syscall(void)
113	sys_vm86old	int sys_vm86old(struct vm86_struct *v86)
114	sys_wait4	long sys_wait4(pid_t pid, unsigned int *stat_addr, int options, struct rusage *ru)
115	sys_swapoff	long sys_swapoff(const char *specialfile)
116	sys_sysinfo	long sys_sysinfo(struct sysinfo *info)
117	sys_ipc	int sys_ipc(uint call, int first, int second, int third, void *ptr, long fifth)
118	sys_fsync	long sys_fsync(unsigned int fd)
119	sys_sigreturn	int sys_sigreturn(unsigned long __unused)
120	sys_clone	int sys_clone(struct pt_regs regs)
121	sys_setdomainname	long sys_setdomainname(char *name, int len)
122	sys_newuname	long sys_newuname(struct new_utsname *name)
123	sys_modify_ldt	int sys_modify_ldt(int func, void *ptr, unsigned long bytecount)
124	sys_adjtimex	long sys_adjtimex(struct timex *txc_p)
125	sys_mprotect	long sys_mprotect(unsigned long start, size_t len, unsigned long prot)
126	sys_sigprocmask	long sys_sigprocmask(int how, old_sigset_t * set, old_sigset_t * oset)
127	sys_create_module	unsigned long sys_create_module(const char *name_user, size_t size)
128	sys_init_module	long sys_init_module(const char *name_user, struct module *mod_user)
129	sys_delete_module	long sys_delete_module(const char *name_user)
130	sys_get_kernel_syms	long sys_get_kernel_syms(struct kernel_sym *table)
131	sys_quotactl	long sys_quotactl(unsigned int cmd, const char *special, qid_t id, caddr_t addr)
132	sys_getpgid	long sys_getpgid(pid_t pid)
133	sys_fchdir	long sys_fchdir(unsigned int fd)
134	sys_bdflush	long sys_bdflush(int func, long data)
135	sys_sysfs	long sys_sysfs(int option, unsigned long arg1, unsigned long arg2)
136	sys_personality	long sys_personality(u_long personality)
137	sys_ni_syscall	long sys_ni_syscall(void)
138	sys_setfsuid16	long sys_setfsuid16(old_uid_t uid)
139	sys_setfsgid16	long sys_setfsgid16(old_gid_t gid)
140	sys_llseek	long sys_llseek(unsigned int fd, unsigned long offset_high, unsigned long offset_low, loff_t * result, unsigned int origin)
141	sys_getdents	long sys_getdents(unsigned int fd, void *dirent, unsigned int count)
142	sys_select	long sys_select(int n, fd_set * inp, fd_set * outp, fd_set * exp, struct timeval *tvp)
143	sys_flock	long sys_flock(unsigned int fd, unsigned int cmd)
144	sys_msync	long sys_msync(unsigned long start, size_t len, int flags)
145	sys_readv	ssize_t sys_readv(unsigned long fd, const struct iovec * vector, unsigned long count)
146	sys_writev	ssize_t sys_writev(unsigned long fd, const struct iovec * vector, unsigned long count)
147	sys_getsid	long sys_getsid(pid_t pid)
148	sys_fdatasync	long sys_fdatasync(unsigned int fd)
149	sys_sysctl	long sys_sysctl(struct __sysctl_args *args)
150	sys_mlock	long sys_mlock(unsigned long start, size_t len)
151	sys_munlock	long sys_munlock(unsigned long start, size_t len)
152	sys_mlockall	long sys_mlockall(int flags)
153	sys_munlockall	long sys_munlockall(void)
154	sys_sched_setparam	long sys_sched_setparam(pid_t pid, struct sched_param *param)
155	sys_sched_getparam	long sys_sched_getparam(pid_t pid, struct sched_param *param)
156	sys_sched_setscheduler	long sys_sched_setscheduler(pid_t pid, int policy, struct sched_param *param)
157	sys_sched_getscheduler	long sys_sched_getscheduler(pid_t pid)
158	sys_sched_yield	long sys_sched_yield(void)
159	sys_sched_get_priority_max	long sys_sched_get_priority_max(int policy)
160	sys_sched_get_priority_min	long sys_sched_get_priority_min(int policy)
161	sys_sched_rr_get_interval	long sys_sched_rr_get_interval(pid_t pid, struct timespec *interval)
162	sys_nanosleep	long sys_nanosleep(struct timespec *rqtp, struct timespec *rmtp)
163	sys_mremap	unsigned long sys_mremap(unsigned long addr, unsigned long old_len, unsigned long new_len, unsigned long flags, unsigned long new_addr)
164	sys_setresuid16	long sys_setresuid16(old_uid_t ruid, old_uid_t euid, old_uid_t suid)
165	sys_getresuid16	long sys_getresuid16(old_uid_t * ruid, old_uid_t * euid, old_uid_t * suid)
166	sys_vm86	int sys_vm86(unsigned long subfunction, struct vm86plus_struct *v86)
167	sys_query_module	long sys_query_module(const char *name_user, int which, char *buf, size_t bufsize, size_t * ret)
168	sys_poll	long sys_poll(struct pollfd *ufds, unsigned int nfds, long timeout)
169	sys_nfsservctl
170	sys_setresgid16	long sys_setresgid16(old_gid_t rgid, old_gid_t egid, old_gid_t sgid)
171	sys_getresgid16	long sys_getresgid16(old_gid_t * rgid, old_gid_t * egid, old_gid_t * sgid)
172	sys_prctl	long sys_prctl(int option, unsigned long arg2, unsigned long arg3, unsigned long arg4, unsigned long arg5)
173	sys_rt_sigreturn	int sys_rt_sigreturn(unsigned long __unused)
174	sys_rt_sigaction	long sys_rt_sigaction(int sig, const struct sigaction *act, struct sigaction *oact, size_t sigsetsize)
175	sys_rt_sigprocmask	long sys_rt_sigprocmask(int how, sigset_t * set, sigset_t * oset, size_t sigsetsize)
176	sys_rt_sigpending	long sys_rt_sigpending(sigset_t * set, size_t sigsetsize)
177	sys_rt_sigtimedwait	long sys_rt_sigtimedwait(const sigset_t * uthese, siginfo_t * uinfo, const struct timespec *uts, size_t sigsetsize)
178	sys_rt_sigqueueinfo	long sys_rt_sigqueueinfo(int pid, int sig, siginfo_t * uinfo)
179	sys_rt_sigsuspend	int sys_rt_sigsuspend(sigset_t * unewset, size_t sigsetsize)
180	sys_pread	ssize_t sys_pread(unsigned int fd, char *buf, size_t count, loff_t pos)
181	sys_pwrite	ssize_t sys_pwrite(unsigned int fd, const char *buf, size_t count, loff_t pos)
182	sys_chown16	long sys_chown16(const char *filename, old_uid_t user, old_gid_t group)
183	sys_getcwd	long sys_getcwd(char *buf, unsigned long size)
184	sys_capget	long sys_capget(cap_user_header_t header, cap_user_data_t dataptr)
185	sys_capset	long sys_capset(cap_user_header_t header, const cap_user_data_t data)
186	sys_sigaltstack	int sys_sigaltstack(const stack_t * uss, stack_t * uoss)
187	sys_sendfile	ssize_t sys_sendfile(int out_fd, int in_fd, off_t * offset, size_t count)
188	sys_ni_syscall	long sys_ni_syscall(void)
189	sys_ni_syscall	long sys_ni_syscall(void)
190	sys_vfork	int sys_vfork(struct pt_regs regs)
191	sys_getrlimit	long sys_getrlimit(unsigned int resource, struct rlimit *rlim)
192	sys_mmap2	long sys_mmap2(unsigned long addr, unsigned long len, unsigned long prot, unsigned long flags, unsigned long fd, unsigned long pgoff)
193	sys_truncate64	long sys_truncate64(const char *path, loff_t length)
194	sys_ftruncate64	long sys_ftruncate64(unsigned int fd, loff_t length)
195	sys_stat64	long sys_stat64(char *filename, struct stat64 *statbuf, long flags)
196	sys_lstat64	long sys_lstat64(char *filename, struct stat64 *statbuf, long flags)
197	sys_fstat64	long sys_fstat64(unsigned long fd, struct stat64 *statbuf, long flags)
198	sys_lchown	long sys_lchown(const char *filename, uid_t user, gid_t group)
199	sys_getuid	long sys_getuid(void)
200	sys_getgid	long sys_getgid(void)
201	sys_geteuid	long sys_geteuid(void)
202	sys_getegid	long sys_getegid(void)
203	sys_setreuid	long sys_setreuid(uid_t ruid, uid_t euid)
204	sys_setregid	long sys_setregid(gid_t rgid, gid_t egid)
205	sys_getgroups	long sys_getgroups(int gidsetsize, gid_t * grouplist)
206	sys_setgroups	long sys_setgroups(int gidsetsize, gid_t * grouplist)
207	sys_fchown	long sys_fchown(unsigned int fd, uid_t user, gid_t group)
208	sys_setresuid	long sys_setresuid(uid_t ruid, uid_t euid, uid_t suid)
209	sys_getresuid	long sys_getresuid(uid_t * ruid, uid_t * euid, uid_t * suid)
210	sys_setresgid	long sys_setresgid(gid_t rgid, gid_t egid, gid_t sgid)
211	sys_getresgid	long sys_getresgid(gid_t * rgid, gid_t * egid, gid_t * sgid)
212	sys_chown	long sys_chown(const char *filename, uid_t user, gid_t group)
213	sys_setuid	long sys_setuid(uid_t uid)
214	sys_setgid	long sys_setgid(gid_t gid)
215	sys_setfsuid	long sys_setfsuid(uid_t uid)
216	sys_setfsgid	long sys_setfsgid(gid_t gid)
217	sys_pivot_root	long sys_pivot_root(const char *new_root, const char *put_old)
218	sys_mincore	long sys_mincore(unsigned long start, size_t len, unsigned char *vec)
219	sys_madvise	long sys_madvise(unsigned long start, size_t len, int behavior)
220	sys_getdents64	long sys_getdents64(unsigned int fd, void *dirent, unsigned int count)
221	sys_fcntl64	long sys_fcntl64(unsigned int fd, unsigned int cmd, unsigned long arg)
222	sys_ni_syscall	long sys_ni_syscall(void)
223	sys_ni_syscall	long sys_ni_syscall(void)
224	sys_gettid	long sys_gettid(void)
225	sys_readahead	ssize_t sys_readahead(int fd, loff_t offset, size_t count)
226	sys_setxattr	long sys_setxattr(char *path, char *name, void *value, size_t size, int flags)
227	sys_lsetxattr	long sys_lsetxattr(char *path, char *name, void *value, size_t size, int flags)
228	sys_fsetxattr	long sys_fsetxattr(int fd, char *name, void *value, size_t size, int flags)
229	sys_getxattr	ssize_t sys_getxattr(char *path, char *name, void *value, size_t size)
230	sys_lgetxattr	ssize_t sys_lgetxattr(char *path, char *name, void *value, size_t size)
231	sys_fgetxattr	ssize_t sys_fgetxattr(int fd, char *name, void *value, size_t size)
232	sys_listxattr	ssize_t sys_listxattr(char *path, char *list, size_t size)
233	sys_llistxattr	ssize_t sys_llistxattr(char *path, char *list, size_t size)
234	sys_flistxattr	ssize_t sys_flistxattr(int fd, char *list, size_t size)
235	sys_removexattr	long sys_removexattr(char *path, char *name)
236	sys_lremovexattr	long sys_lremovexattr(char *path, char *name)
237	sys_fremovexattr	long sys_fremovexattr(int fd, char *name)
238	sys_tkill	long sys_tkill(int pid, int sig)
239	sys_sendfile64	ssize_t sys_sendfile64(int out_fd, int in_fd, loff_t * offset, size_t count)
240	sys_ni_syscall	long sys_ni_syscall(void)
241	sys_ni_syscall	long sys_ni_syscall(void)
242	sys_ni_syscall	long sys_ni_syscall(void)
243	sys_ni_syscall	long sys_ni_syscall(void)
244	sys_ni_syscall	long sys_ni_syscall(void)
245	sys_ni_syscall	long sys_ni_syscall(void)
246	sys_ni_syscall	long sys_ni_syscall(void)
247	sys_ni_syscall	long sys_ni_syscall(void)
248	sys_ni_syscall	long sys_ni_syscall(void)
249	sys_ni_syscall	long sys_ni_syscall(void)
250	sys_ni_syscall	long sys_ni_syscall(void)
251	sys_ni_syscall	long sys_ni_syscall(void)
252	sys_ni_syscall	long sys_ni_syscall(void)
253	sys_ni_syscall	long sys_ni_syscall(void)
254	sys_ni_syscall	long sys_ni_syscall(void)
255	sys_ni_syscall	long sys_ni_syscall(void)
256	sys_ni_syscall	long sys_ni_syscall(void)
257	sys_ni_syscall	long sys_ni_syscall(void)
258	sys_ni_syscall	long sys_ni_syscall(void)
259	sys_ni_syscall	long sys_ni_syscall(void)

]]> https://www.jollen.org/blog/2006/10/linux_2429_system_calls_table_1.html https://www.jollen.org/blog/2006/10/linux_2429_system_calls_table_1.html Linux Device Drivers & Kernel Sat, 07 Oct 2006 13:11:24 +0800 _nss_service_function 當我們呼叫 gethostbyname_r() 函數時 (或 gethostbyname)，假設我們在 /etc/nsswitch.conf 裡有一行這樣的設定： hosts: files 那麼根據之前 Jollen 在 Blog 裡的說明，此時會使用到的 NSS module 會是 libnss_files.so.2，並且以下的 routine 會被呼叫： _nss_files_gethostbyname_r 查看一下： # nm /lib/libnss_files.so.2 |egrep "gethostbyname" 00004320 T _nss_files_gethostbyname2_r 00003ba0 T _nss_files_gethostbyname_r 現在我們終於知道了，當我們呼叫查詢的函數 'function' 時，在 libnss_SERVICE.so.2 裡的相對應函數便會被呼叫，此函數的 naming 方式為： _nss_service_function 另外，NSS module 僅包含 reentrant 的版本。 最後我們要講的是，gethostbyename() 與 gethostbyname_r()，或是之前提到的 getpwnam() 都是實作在 libc.so.6 裡的。For example： # nm /lib/libc.so.6 |egrep "T.gethostbyname" 000f72b0 T gethostbyname 000f7480 T gethostbyname2 000f78c0 T gethostbyname2_r@GLIBC_2.0 000f7660 T gethostbyname2_r@@GLIBC_2.1.2 000f7b80 T gethostbyname_r@GLIBC_2.0 000f7930 T gethostbyname_r@@GLIBC_2.1.2 # nm /lib/libc.so.6 |egrep "T.getpwnam" 000acf50 T getpwnam 000ad5c0 T getpwnam_r@GLIBC_2.0 000ad440 T getpwnam_r@@GLIBC_2.1.2 這就是為什麼我們在 ldd (or objdump) 時，都看不到 libnss_SERVICE.so.6 的道理．當我們做查詢時，NSS 才去載入對應的 service module。]]> https://www.jollen.org/blog/2006/10/name_service_switch.html https://www.jollen.org/blog/2006/10/name_service_switch.html GNU Toolchains & Linux Systems Programming Wed, 04 Oct 2006 14:30:21 +0800 System Database NSS 支援 11 種資料庫名稱：aliases、ethers、group、hosts、netgroup、networks、protocols、passwd、rpc、services 與 shadow。分別說明如下。 aliases: Mail 別名 ethers: Ethernet 號碼 group: 使用者群組資料庫，即 /etc/group hosts: Host names 與 IP 對應資料庫，即 /etc/hosts 或是利用 name server 轉換 netgroup: "hostname username domainname" 的組合稱為 netgroup networks: 即 /etc/networks protocols: 通訊協定資料庫，即 /etc/protocols passwd: 使用者名稱資料庫，即 /etc/passwd rpc: Remote procedure call 資料庫 services: 即 /etc/services 資料庫 shadow: 即 /etc/shadow 檔 NSS Service 與 Lookup NSS 支援 7 種服務類型，說明如下。 1. nisplus (or nis+): 使用 NIS+ (NIS version 3) 服務 2, nis (or yp): 使用 NIS (NIS version 2) 服務 (也叫 YP, YellowPage) 3. dns: 使用 DNS (Domain Name Service) 服務 4. files: 使用一般的檔案讀取服務 5. db: 使用 database (.db) 檔案讀取服務 6. compat: 使用 NIS compat mode 服務 7. hesiod: 使用 Hesiod 服務做 user lookups GNU 的實作是把每一個服務 (service) 實作成不同的 module (shared library)，因此可以在 GNU/Linux 系統底下找到這些相對應的 shared libraries： libnss_nisplus.so.2 libnss_nis.so.2 libnss_dns.so.2 libnss_files.so.2 libnss_compat.so.2 libnss_hesiod.so.2 不過其實還有下面 3 個： /lib/libnss_ldap.so.2 /lib/libnss_winbind.so.2 /lib/libnss_wins.so.2 GNU 的 NSS module 是以 libnss_SERVICE.so.2 來命名。 在這些 module (library) 裡的函數，是無法讓程式直接使用的，因此了解這些 module 裡的函數如何被使用 (呼叫) 是一個重要且有趣的題目。 查詢前面所提 11 種資料庫資訊的動作稱為 lookup，lookup 的方法便是 NSS 的服務類型 (NSS service)，也就是我們可以利用以上共 7 種方式來查詢 system database；不過，以 files、db、nis 與 nisplus 這 4 種方式是比較常用的。 由此可知，不同的 system database 可以用不同的服務來做查詢。因此，系統管理員必須告訴 NSS，我們想要他利用哪一種服務類型，來查詢 (lookup) 指定的 system database。這個動作的管理方式便是透過 /etc/nsswitch.conf 設定檔來完成。 /etc/nsswitch.conf 看一下 glibc-2.3.3 預設定 nsswitch.conf 設定檔內容如下：

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
#
passwd:         db files
group:          db files
shadow:         db files
hosts:          files dns
networks:       files dns
protocols:      db files
services:       db files
ethers:         db files
rpc:            db files
netgroup:       db files

這樣其實就很清楚了，例如：passwd 資料庫 (/etc/passwd) 的讀取方式 (lookup service) 有 db/files 二種。以 embedded Linux 系統來說，我們會這樣設定： passwd: files 也就是說，直接以檔案讀取方式來查詢 /etc/passwd。那麼，之前提過的 embedded Linux 系統建置之 thttpd 個案分析，為何需要 libnss_files.so.2 檔案，觀念就很清楚了。 此外，大家也可以了解一下 red hat linux 或其它 Linux distribution 的 nsswitch.conf 設定佈署方式。 這個部份的文件主要是 glibc 的手冊，大家可參考 http://www.gnu.org/software/libc/manual/html_node/Name-Service-Switch.html#Name-Service-Switch -- jollen 作者／陳俊宏 http://www.jollen.org]]> https://www.jollen.org/blog/2006/10/name_service_switch_1.html https://www.jollen.org/blog/2006/10/name_service_switch_1.html GNU Toolchains & Linux Systems Programming Tue, 03 Oct 2006 22:21:14 +0800 關於建構 thttpd 的案例 thttpd 使用到 NSS (Name Service Switch)，因此若沒有將 libnss_SERVICE.so 加到 root filesystem，thttpd 在執行時可能會遇到一些奇怪的問題。舉個例子，當 thttpd 透過 /etc/passwd 去尋找 (查詢) UNIX user 時，會用到 libnss_files.so (不讀 /etc/shadow)，因此會看到以下的錯誤訊息： unknown user - root 出現這個錯誤的原因是 thttpd 讀不到 'root' 使用者，要深入探討這個問題的原理，必須從以下的程式碼片斷開始探討：

    403     /* If we're root and we're going to become another user, get the uid        /gid
    404     ** now.
    405     */
    406     if ( getuid() == 0 )
    407         {
    408         pwd = getpwnam( user );
    409         if ( pwd == (struct passwd*) 0 )
    410             {
    411             syslog( LOG_CRIT, "unknown user - '%.80s'", user );
    412             (void) fprintf( stderr, "%s: unknown user - '%s'\n", argv0,         user );
    413             exit( 1 );
    414             }
    415         uid = pwd->pw_uid;
    416         gid = pwd->pw_gid;
    417         }

這段程式碼是 thttpd 2.25b 的程式片斷，位於 thttpd.c 的 main() 函數裡。關於 libnss_SERVICE.so 的議題，Jollen 打算另外再做討論，因為還會與 libc 有關係。 在這裡我們由系統建構的角度來看這個問題。因為我們已經習慣用 objdump 來觀察程式的相依 library，所以當 objdump 的畫面跟我們預期的不同時，經常一時無法反應過來。例如，以下的訊息是我們所「預期」的：

# /opt/crosstool/gcc-3.4.1-glibc-2.3.3/arm-9tdmi-linux-gnu/bin/arm-9tdmi-linux-gnu-objdump -x thttpd|more
...
Dynamic Section:
  NEEDED      libcrypt.so.1
  NEEDED      libnss_files.so.2
  NEEDED      libc.so.6
...

但是實際的訊息卻是像這樣的：

# /opt/crosstool/gcc-3.4.1-glibc-2.3.3/arm-9tdmi-linux-gnu/bin/arm-9tdmi-linux-gnu-objdump -x thttpd|more
...
Dynamic Section:
  NEEDED      libcrypt.so.1
  NEEDED      libc.so.6
...

我們可以用一知半解的思考邏輯來解決問題：thttpd 呼叫到 getpwnam() 函數，此函數由 libnss_compat 提供，因此解決方案是把 libnss_files.so 加到 root filesystem 裡即可。 且慢！前面才講到 libnss_compat，怎麼後面是把 libnss_files 加到 root filesystem？是這樣的，libnss_compat 用來讀 /etc/shadow，但是現在我們只需要由 /etc/passwd 讀 Unix user，所以使用 libnss_files.so 就行了。 執行 thttpd 的話，再加上指定 username 的參數來執行： # thttpd -p 80 -d /var/www -u root libnss_SERVICE.so 是包含在 glibc 裡的程式庫，因此可以直接由 cross toolchain 裡取得，不必再另行建置。 有關 NSS (Name Service Switch) 可參考以下網頁: Linux / Unix Command: nsswitch.conf - http://linux.about.com/od/commands/l/blcmdl5_nsswitc.htm 其它網路資源: http://www.gnu.org/software/libc/manual/html_node/Name-Service-Switch.html http://mirrors.usc.edu/pub/gnu/Manuals/glibc-2.2.3/html_chapter/libc_28.html 此處我們以「service」的角度來探討這個問題：因為 thttpd 使用到 Name Service Switch，所以需要加入 libnss_SERVICE.so。另外一種探討的角度是：由 programming 的角度來思考，大家可以試著去研究這個問題，還挺好玩的！ 附帶一提，如果要讀 shadow passwd 的話，是使用 libnss_compat.so。]]> https://www.jollen.org/blog/2006/10/library_dependency_1.html https://www.jollen.org/blog/2006/10/library_dependency_1.html Embedded Linux: Platforms and Applications Tue, 03 Oct 2006 17:57:18 +0800 簡報下載 #3: mesh networking 可以取代 Wi-Fi "hot spots" 的架構，並且簡省無線網路的佈署成本，由於我們以現有的 802.11a+g 的無線網卡來實作，因此可以使用許多現成的 open source 軟體來配合。以藉此達成單點對多點 (point to multipoint)、多點對多點 (multipoint to multipoint) 或是單點對單點 (point-to-point) 的架構實作。 #6: 這是我們所期望做到的規格 (specification)，很有趣的是，開放源碼套件居然能滿足我們所開出的所有規格，這意謂我們的 project 需要自己開發軟體的機會幾乎是 0%；事實上，我們 90% 以上的工作都是在做系統整合 (Linux administration) 和 UI (web-based) 的開發。 #7: 這是一個實際 (real-world) 的案例，讓我們來說明我們倒底在 root filesystem 裡放了哪些東西，以及「如何加入」這些東西。 #8: 要 build 一個基本的 wireless 嵌入式 Linux 系統 (root filesystem)，我們會需要這些基本的開放源碼套件，另外由於 zeroconf 遭遇到專利問題，因此我們並沒有在這份簡單裡展示 zeroconf IP 的功能。 #9: 再來是 Linux 的無線網路解決方案，在驅動程式方面，我們使用的 Atheros 與 Prism 晶片都有支援。在 user application 方面，wireless routing protocol 的解決方案是 quagga，這是一個相當知名的 open source 專案。另外，wireless tools 是必備的，因此我們要透過它來設定無線網路。 #16: 這是我們利用 iwconfig 在 Kendin 平臺上啟動無線網路的畫面，ath0 介面是 Atheros 網卡 (802.11g)，eth2 是 Intersil 網路 (802.11b/g)。 #17: 我們把 ath0 設定成 "ad-hoc" 模式。 #18: 利用 'iwlist' 指令偵測 channel。 #19: 利用 'iwlist' 掃描 eth2 介面。 ps. 不知道大家還想要哪一頁的詳細講稿 @@" ]]> https://www.jollen.org/blog/2006/10/post_1.html https://www.jollen.org/blog/2006/10/post_1.html Embedded Linux: Platforms and Applications Mon, 02 Oct 2006 23:58:18 +0800 註明出處 ]]> https://www.jollen.org/blog/2006/09/os.html https://www.jollen.org/blog/2006/09/os.html Embedded Linux: Platforms and Applications Sat, 30 Sep 2006 13:39:23 +0800 圖: LiPS　的工作範圍（kernel 部份是OSDL的任務） (Source: LinuxDevices.com / LiPS) LiPS的主要任務為「標準化（standardizing）Linux手機」，並提出可行的Linux手機OS架構。更明確來說，LiPS在標準化「Linux手機的middleware層」，middleware提供電話功能的API、GUI、裝置管理功能、相關的安全性管理、電話簿功能。今年下半年將可以看到LiPS釋出的第一版Linux手機規格！ 除了LiPS外，OSDL（Open Source Development Labs）也未曾缺席Linux的手機發展，OSDL裡的MLI（Mobile Linux Initiative）也於２００５年成立，MLI的任務為「maximize the market opportunity for Linux-based devices」。目前的成員有：MontaVista Software, Motorola, PalmSource, Trolltech, Wind River。 LiPS與OSDL的合作相當密切，LiPS著重moddleware的規格定義，OSDL的MLI則是著墨於kernel層。MLI的任務是發展出適合Linux mobile phone使用的kernel，LiPS的任務是發展出明確的手機軟體架構（software stack）。 Mobilinux 4.0 Mobilinux是目前可以取得，最具體的Linux手機產品。 Mobilinux 4.0是MontaVista的新一代主力產品，Mobilinux 4.0其實是由MontaVista原先的Linux Consumer Electronics Edition (CEE) 3.1 與 Linux Consumer Professional Edition (Pro) 3.1 產品所延伸而來的新一代Linux mobile phone OS。 Linux Consumer Electronics Edition (CEE) 3.1 與 Linux Consumer Professional Edition (Pro) 3.1 已是 design win 的產品，市面上可看到十多款的手機產品。 Mobilinux 4.0使用2.6系列的kernel，real-time的支援與效能表現比以往更優秀，Mobilinux 4.0也承習Linux CEE的電源管理（power management）強化功能。Mobilinux 4.0的real-time patch是Open Source Real-time Linux Project的成果。 * Mobilinux - http://mobilinux.com/ * Linux 手機展示場 - http://www.linuxdevices.com/articles/AT9423084269.html kernel 2.6的一個重要特色是：支援SD/SDIO/MMC，Mobilinux 4.0也強化對SD/SDIO/MMC的支援，對於Linux手機的應用是相當重要的里程碑。




圖: 基於 Mobilinux 的 Linux 智慧型手機（由上至下依序是：Motorola A728、Motorola E680、NEC N700i、NEC N902i、Panasonic P902i） 目前Mobilinux的design win手機產品有15支，所有的Mobilinux Linux手機可以到Mobilinux網站查詢。 -- 作者／陳俊宏 (jollen) 原文刊載於 Run! PC 雜誌 9 月號 歡迎任意轉貼引用．但請務必註明出處]]> https://www.jollen.org/blog/2006/09/linux_smartphone.html https://www.jollen.org/blog/2006/09/linux_smartphone.html Embedded Linux: Platforms and Applications Sat, 30 Sep 2006 12:48:38 +0800 現在的嵌入式系統學習主軸 現今嵌入式系統的實作，幾乎都會加入嵌入式作業系統（embedded OS）的元素，有了作業系統，我們都可以為目標裝置「寫軟體」。總合來看，如果要學習所謂的嵌入式系統，從熱門的WinCE或Embedded Linux領域切入是相當不錯的選擇。 驅動程式是「寫軟體」與「做硬體」的 “connectivity”，因此現今資訊業界最熱門的嵌入式系統學習主軸為驅動程式的設計。 WinCE驅動程式 WinCE驅動程式的核心人物當然就是在WDM（Windows Driver Model）身上了。WDM是Windows 98/2000之後的驅動程式架構，WDM是一個嚴密的分層（layered）架構，架構層間以IRPs（I/O Request Packets）做通訊。 WDM驅動程式分為三種類型：bus driver、function driver與filter driver。Bus driver是device-independent的驅動程式，主要在驅動I/O bus，例如：PCI bus driver、USB bus driver；function driver是 “device” 的驅動程式，我們常講的「驅動程式設計」大部份都是講 function driver，function driver 主要在驅動各種裝置，因此大多是由裝置廠造商撰寫並提供給使用者安裝，function driver 的設計大多著墨在「讀/寫」外部裝置。Filter driver是非必要的驅動程式，主要在過瀘 I/O requests。 WDM驅動程式的設計是使用Windows DDK，學習資源豐富並且完整；相較於Linux驅動程式，WDM驅動程式的學習材料較系統化。 Linux驅動程式 Linux驅動程式採取嚴謹的分層式架構設計（layered architecture），利用分層的架構設計來徹底區分generic device driver（machine independent）與machine dependent driver。 Linux驅動程式採用分層架構的觀念設計，透過「註冊」與「回呼」的機制來清楚地區分每一層的關係。分層架構的實作必須在下層將自己註冊給上層，上層再回呼下層；上層的驅動程式必須提供註冊函數供下層呼叫，下層驅動程式所使用的註冊函數也將決定自己的上層架構。 與 user application 如何互動，是撰寫驅動程式時所要考慮的重要一環，因此在撰寫驅動程式時，要提供什麼「功能」給應用程式引用，就必須事先定義清楚。Linux的generic device driver層已經幫我們把這些功能定義清楚了。Linux驅動程式如何透過 I/O port 或 I/O memory來控制裝置，也就是與晶片組的溝通，方式是使用 Linux kernel 所提供的I/O函數來存取並控制實體硬體裝置。 Linux驅動程式的學習困難度較高，並且也沒有像是Windows DDK這樣的完整開發工具；但是若能掌握正確的學習步驟，要邁向高手之路並非遙不可及。 -- 作者／陳俊宏 (jollen) 原文刊載於 Run! PC 雜誌 8 月號 歡迎任意轉貼引用．但請務必註明出處]]> https://www.jollen.org/blog/2006/09/post.html https://www.jollen.org/blog/2006/09/post.html Linux Device Drivers & Kernel Sat, 30 Sep 2006 12:46:06 +0800 超熱門美食：嵌入式系統 什麼是「嵌入式系統」？這個熱到不行的題目倒底是什麼東西！嵌入式系統已經是全球科技業的共通話題了，就讓我們來簡單說明什麼叫「嵌入式系統」（Embedded Systems）吧。 美國工程師協會所定義的．．．嗯！看到這句話大家大概又要傻眼了，怎麼每個人解釋嵌入式系統都要搬出美國工程師協會的定義來交差呢！這真的是落伍啦。嵌入式系統不過是廣義還是狹義的定義，肯定都是包山包海的又臭又長。 我們這裡所要講的嵌入式系統目標是鎖定在熱門的「嵌入式作業系統平臺技術」（Embedded OS），所以如果我們再繼續縮小主題的話，沒錯！題目就只剩下 WinCE、Symbian 與 Linux 了！ 如果以學習熱度來講的話，WinCE與 Embedded Linux 絕對是不「二」主題。所以我們要講的嵌入式系統就是Windows Mobile與Embedded Linux。本文將會明確鎖定幾個主題，並給予一個學習的方向，讓有志進入嵌入式系統領域的朋友能抓住主要的幾個主題。 功能導向的系統 言歸正傳，所謂的嵌入式系統簡而言之是一種「執行部份特定功能」的系統，實作上並不限定技術範疇，只要能將特定的功能（function）「嵌入」到目標裝置（target device）裡，包含這些功能的整體系統（或平臺）即是「嵌入式系統」。 一部目標裝置裡頭，可能會有數十個甚致數百、數千個嵌入式系統，每個「系統」均負責執行一項專責的功能。 由於目前的目標裝置都必須嵌入甚為複雜的功能，所以「嵌入式作業系統」成為嵌入式系統不可或缺的要素。例如，一支完全沒有生命力的「手機硬體」，在嵌入Windows Mobile與application後，就變成可以聽MP3、跟女朋友聊天、看MTV與使用各種功能的活力裝置了！有了完整的嵌入式系統技術，任何目標裝置都會因為嵌入式系統的注入，而產生生命，充滿活力！ 目標裝置導向的系統 由於嵌入式系統是功能導向的系統，因此必須設計、選擇或購買正確（或適合）的目標裝置，才能開始實作並嵌入「嵌入式系統」。因此，嵌入式系統的技術是以功能與目標裝置為分類的一種技術。 例如，與PDA相關的目標裝置（即硬體）、與MP3撥放器相關的目標裝置、與3G手機相關的目標裝置等等；使用這些目標裝置所開發的特定功能系統，便是PDA的嵌入式系統、MP3音樂撥放的嵌入式系統、3G手機的嵌入式系統。 附帶值得一提的是，由於嵌入式系統的目標裝置，在硬體規格或架構上往往重疊性很大，所以很多SOC的廠商都會推出所謂的「公板」或「參考設計」（Reference Design），下游的開發者往往只要把公板做部份修改或小量的客製化，即可滿足自己的需求。 使用嵌入式作業系統 因為以功能為導向，因此當要嵌入的功能很複雜或非常多樣化時，使用嵌入式作業系統才能解決許多技術面的問題。有了嵌入式作業系統，「功能的實作」往往只是在「寫程式」，所以最終可以把嵌入式系統變成軟體開發的工作。 目標裝置 (Target Device) 的特性 嵌入式系統大多數都不使用標準的IBM PC硬體，而且有些嵌入式系統的目標裝置都是很特殊的。不過，我們可以將嵌入式系統目標裝置（target device）的主要硬體差異做一個說明。 我們透過與IBM PC的差異比較來做解釋。 嵌入式系統使用SOC（System-on-Chip）的處理器，這些SOC都是專為嵌入式系統或是手持行動裝置設計的，因此具備低功率、低耗電與面積小的特色。 在RAM方面，嵌入式系統的RAM大多在2MB到128MB之間，並且都是屬是SRAM/SDRAM的技術。很少使用IBM PC規格的DDR記憶體。 在儲存裝置方面，嵌入式系統採用NAND flash技術來存放系統程式。例如iPOD就有一部份產品使用NAND flash來存放MP3。使用NAND flash做為主要的儲存裝置是嵌入式系統的主要趨勢之一。 嵌入式系統主要透過序列埠輸出資訊；而個人電腦則是透過VGA顯示卡顯示圖形資料，嵌入式系統大多使用TFT-LCE做為圖形介面。 個人電腦當然是一般用途（general-purpose）的電腦，因此可以安裝許多有趣的應用軟體。嵌入式系統則是屬於特定用途（specific-purpose）的電腦，主要是針對特定功能所設計。 WinCE簡介 由於微軟的智慧型手機與台灣代工伙伴合作的成功，使得Windows Mobile成為大家耳熟能詳的嵌入式系統技術。那麼Windows Mobile與Windows CE到底是不是一樣的東西？ 基本上，Windows Mobile與Windows CE是一樣的；Windows CE是微軟專為嵌入式系統所推出的embedded OS，Windows CE可應用於網路設備、Set-top-Box、工業控制器等嵌入式裝置。 Windows Mobile 5.0採用Windows CE 5.0的核心，是專為PocketPC與Smartphone所推出的產品。WinCE的開發環境可以相當低的花費取得，甚致可以取得免費版本；Windows Mobile的開發環境則是必須經由微軟授權後取得。 WinCE的產品開發門檻底、程式開發工具友善使用性佳、使用者介面豐富與完整的多媒體支援，使得WinCE在行動手持裝置的產品開發上具備相當的優勢。 以專為智慧型手機推出的Windows Mobile 5.0來說，除了使用性佳的操作介面與強大的多媒體撥放支援外，更可以執行Mobile Office套裝軟體（Word Mobile、PowerPoint Mobile Viewer等）、使用MSN與收發Email等。 Windows Mobile上能執行許多PC上常用的許多應用程式，例如：Mobile IE、Windows Media Player 10 Mobile 5，都是讓Windows Mobile智慧型手機更聰明好用的關鍵。在嵌入式軟體開發方面，Windows Mobile支援 .NET CF（Compact Framework）；開發工具目前也整合成一套Visual Studio 2005，開發Windows Mobile的應用程式更加輕鬆愉快；需要資料庫應用的應用程式，也能使用SQL Mobile解決方案。 Embedded Linux簡介 Embedded Linux其實並不是一個作業系統，而是代表「應用Linux系統於embedded system」的名詞。因此用即是Embedding Linux來說明Embedded Linux技術是再恰當不過了。Embedded Linux的技術核心主軸是在研究「如何將Linux系統嵌入至嵌入式目標裝置裡」。 根據William E. Peisel 於Whitepaper: Embedding Linux一文對Embedded Linux的看法，Embedded Linux的定位為：「A software platform for embedded systems and devices」。 嵌入式Linux系統的技術主軸有二：(1) Linux kernel 與 (2) root filesystem。Root filesystem即是「小型的Linux系統」，root filesystem裡頭存放Linux的系統架構（filesystem hierarchy）、指令、工具、應用程式、shared libraries、驅動程式等。 Embedded Linux的root filesystem必須純手工打造（from zero / from scratch），因此熟悉Linux系統的操作、設定與管理是必要的基礎技能。 相較於WinCE友善的程式開發環境，Embedded Linux的開發環境則是比較不容易上手的。目前專門針對Embedded Linux的開發工具尚不成熟，因此我們都是在Linux的”PC”上使用Linux一般性的程式開發工具來進行嵌入式Linux的發展。 Embedded Linux的開發工具，主要以GCC和glibc為核心。GCC（http://www.gnu.org/software/gcc/gcc.html）是GNU Compiler Collection的縮寫，也就是許多編譯器的收集，目前支援的程式語言有：C、C++、Objective-C、Fortran 、Java、Ada。GLIBC是GNU的C標準程式庫，GLIBC提供system call的界面函數與標準的C函數。GLIBC也符合許多標準與規格，讓使用GLIBC的程式可以更容易移植到其它UNIX平臺。 目前應用Embedded Linux技術的產品，大多偏向「非手持型」的嵌入式系統，例如：網路設備、Set-top-box、工業控制器等。 Linux kernel Linux 是一個作業系統核心的實作，Linux kernel 加上其它必要的系統工具 (utilities) 與其它專案程式碼的 Linux 作業系統則稱為 Linux system，一般認為標準的稱呼為 GNU/Linux (system)，這是因為 Linux system 使用的系統工具大多是 GNU 的程式碼。 目前仍在使用本的kernel版本可分為4大分支： 1. Kernel 2.0.x：已經停止發展的早期版本。 2. Kernel 2.2.x：已經停止發展的早期版本。 3. Kernel 2.4.x：重要的版本分支，目前仍廣為使用中，因此仍然持續有驅動程式與處理器架構相關程式碼的更新。 4. Kernel 2.6.x：重要的Linux kernel里程碑，許多新技術、新觀念、驅動程式支援與作業系統架構都在此版本實作，是目前更新最頻繁的版本分支。 目前（2005年）的最新kernel版本為2.6.x系列，由於kernel的開發者很早就已經轉移重心至2.6系列，因此2.4系列的版本分支也將漸漸停止發展。許多2.4版本裡的重大bug也只在2.6系列版本做修正。 2.4 系列的 kernel 仍普遍使用於嵌入式系統中，但缺點是驅動程式的支援較不足；2.6 系列的 kernel 是目前最流行的分支，這個系列的 kernel 加入許多新技術的實作，當然也包含對嵌入式系統的支援，並且具備較完整的驅動程式。 Embedded Linux的重要規格標準 Embedded Linux是基於Linux系統的特殊應用，當然也要符合眾多標準才行。LSB與FHS標準是重要的二大標準，跟隨標準不但可以提供系統間的相容性，也可以提供我們一個Linux系統的建構依據。 由 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 的標準正是在制定這些基本的需求。 LSB Specification共分成二大類型： 1. Generic Specification（LSB-generic）：定義不會經常改變與各處理器同通之一般標準。 2. Architecture Specifications（LSB-arch）：定義不同處理器架構之標準。 完整的 LSB 規格文件為 gLSB 配合特定的 archLSB 文件，若我們以 IA32 之電腦架構為主，應選擇參考 LSB Common 與 LSB IA32 二份文件。 LSB - http://www.linuxbase.org/spec 如何進行LSB 3.0的認證測試：http://www.opengroup.org/lsb/cert/docs/LSB_Certification_Guide.html。 FHS 全名為 Filesystem Hierarchy Standard，是一份定義檔案與目錄標準的文件，FHS 的標準定義了目錄與檔案的擺放位置，而 UNIX-like 的系統則是根據這個標準來管理整個檔案結構。因此，不管是系統廠商、Linux/UNIX distribution 發展者、應用程式作者、套件管理者、系統維護人員都應該要依照 FHS 的標準來管理 UNIX 系統的目錄與檔案。 豐富的Free Software資源 Embedded Linux的特色是大量使用Free Software的資源，「任何你想要的軟體，幾乎都能在網路上找到自由軟體」已經成為Embedded Linux技術的重要支柱。自由軟體資源包山包海，舉凡應用程式、系統工具、網路工具、程式庫、圖形介面、小型瀏覽器、程式發展工具等等都能找得到。 因此學習Embedded Linux有一個很重要的階段就是「玩Linux！」，了解Linux的世界有什麼軟體可以用，對於將來發展Embedded Linux有絕對的幫助。甚致更進一步去學習別人寫程式的技巧，都能累積Embedded Linux的功力。 -- 作者／陳俊宏 (jollen) 原文刊載於 Run! PC 雜誌 8 月號 歡迎任意轉貼引用．但請務必註明出處]]> https://www.jollen.org/blog/2006/09/_run_pc_8.html https://www.jollen.org/blog/2006/09/_run_pc_8.html Embedded Linux: Platforms and Applications Sat, 30 Sep 2006 12:00:55 +0800 原始發問者顯然誤解了 Embedded Linux 的意思，不過有位好心人很邁力地解釋 "regular Linux" 與 "embedded Linux" 的觀念，他的開場白寫的真的很不錯： 'Embedded Linux' is not an application program, it is a kernel and set of libraries and utilities designed to run on an embedded system(for example, a router). 真然是一針見血，講的真好。Embedded Linux 是一個 kernel (for specific-platform) 與一些 libraries/utilities 的集合 (即 root filesystem)；因此所謂的 embedded Linux 通常是以一個 kernel image 與 root filesystem image 的形式 deliver 給 end-user 的。 其實初學 embedded Linux 的同學，也經常被 embedded Linux 的名詞所困惑，因為我們都假設大家對 embedded Linux 都有一定程度的「sense」了，所以很少去解釋 embedded Linux 與一般 Linux 的差異；在對初學者的教育訓練上，我們試著以「Top-down 最小化 Linux 系統」與 embedded Linux distribution (eg. PeeWeeLinux)，再配合 PC Linux 與 embedded Linux 的差異比較來解釋「Linux (GNU/Linux) 系統應用於嵌入式裝置」的觀念，目前看來成效還算不錯呢！ 由於嵌入式 Linux 是「Linux (GNU/Linux) 系統的特殊應用」，因此所有的基本技能 (enabling technologies) 是建構在傳統的 Linux 系統操作與管理能力上的；所以「學 embedded Linux 是不是就不用去學 Linux 指令與 Linux administration」問題的答案肯定是「NO」。]]> https://www.jollen.org/blog/2006/09/embedded_linux_2.html https://www.jollen.org/blog/2006/09/embedded_linux_2.html Embedded Linux: Platforms and Applications Sat, 30 Sep 2006 11:29:09 +0800 QEMU 是一個可以模擬 x86、x86_64、ARM、、SPARC、SPARC64、PowerPC、PowerPC64、MIPS、m68k 與 SH-4 處理器的 open source 軟體。簡單說，QEMU 就是一套虛擬機器 (virtual machine) 的軟體。 QEMU 提供二種模擬模式：(1) Full system emulation；(2) User mode emulation。Full system emulation 模擬完整的系統，即處理器與週邊；user mode emulation 則是能在不同的處理器平臺上執行其它處理器平臺的程式。 以下是引用自 QEMU 官方的介紹： QEMU is a generic and open source processor emulator which achieves a good emulation speed by using dynamic translation. QEMU 的 Status 網頁表列了目前支援的 CPU 與這二種模擬模式的支援狀況。在 QEMU 的 roadmap 裡，也驚見 "Full MAC OS X support as guest OS" 的　計畫，真是令人期待。 網路上有人利用 QEMU 安裝了 Versatile，然後灌了一套 Debian ARM 在玩。看起來頗為有趣，此外，QEMU 應是目前最佳的模擬器首選，這真是學習微處理器系統的好教具。 ]]> https://www.jollen.org/blog/2006/09/qemu.html https://www.jollen.org/blog/2006/09/qemu.html Embedded Linux: Platforms and Applications Thu, 28 Sep 2006 23:38:31 +0800 http://www.gnu.org/software/libiconv/ 把 libiconv 套件解開並編譯後，可以在 src/ 目錄下找到 iconv 執行檔，這是 libiconv 為我們寫好的一個字元轉碼 (conversion) 工具，這個工具相當的實用，比如以 jollen 的網站來說，jollen.org 的網頁是以 unicode 儲存，但是我們發佈的頁面是以 big5 編碼為主，我們所使用的轉換工具便是 iconv。 iconv 的使用可以參考 http://www.gnu.org/software/libiconv/documentation/libiconv/iconv.1.html，我們舉一個例子來說明，比如我想把 big5.txt 文件 (Big5 encode) 轉換成 Unicode (UTF-8)，那麼只要執行： $ iconv -f BIG5 -t UTF-8 big5.txt 就可以了，參數 -f 指定來源編碼，參數 -t 指定目的編碼，編碼後的字串會輸出到 stdout。字元集 BIG5 也可以寫成 BIG-5，或是 BIG-FIVE，或是 BIGFIVE；要怎麼知道 iconv 可以處理 (接受) 哪些字元集 (character set )，只要執行 'iconv -l' 就可以查詢了，輸出結果會是一大票的字元集列表。 這是使用 iconv 工具的方式，假如要自己寫程式的話也是非常簡單的，因為 libiconv 裡頭只有 3 個函數： iconv_t iconv_open (const char* tocode, const char* fromcode)：開啟 libiconv。 size_t iconv (iconv_t cd, const char* * inbuf, size_t * inbytesleft, char* * outbuf, size_t * outbytesleft)：執行轉碼。 int iconv_close (iconv_t cd)：做完轉碼後關閉 libiconv。 libiconv-1.xx/src/iconv.c 本身就是一個很棒的範例了，大家可以參考。 ]]> https://www.jollen.org/blog/2006/09/libiconv_1.html https://www.jollen.org/blog/2006/09/libiconv_1.html GNU Toolchains & Linux Systems Programming Wed, 27 Sep 2006 23:10:52 +0800 Open Firmware。Jollen 最近發現在 OpenBIOS 的專案網站中，出現了一個 FCode Suite 的套件，這是 IBM 的 David Paktor 老兄在八月份 (2006) 丟到 OpenBIOS 專案的貢獻 (不過他在9月5日才發佈這項消息)。 OpenBIOS OpenBIOS 的專案目的是實作一個 IEEE 1275-1994 (即 Open Firmware 標準) 相容的 firmware。ＯpenBIOS 提供的 FCODE Suite 將 ANS Forth 相容的程式碼翻譯成 FCODE 中介形式，可以提供我們開發 platform-independent 的 boot-time device drivers (可以看 David 的 email)。 這裡先暫時把相關的資源 (VGA) 再整理一下，等到公司的 PowerPC 平臺真的 ready 後，才可能有機會來 study FCode Suite。 Video Graphics Array VGA BIOS 提供了一組 VGA 卡的服務函數，實作在主機板上的 BIOS 裡。非常早期的 IBM PC 就有提供 VGA BIOS (或稱為 Video BIOS)。VGA BIOS 主要是一大堆 screen I/O 的函數，這是 x86 架構下的產物，自然也就以 x86 assembly 寫成。 VGA BIOS 歷經歲月的擴充與積累，一直到 1987 年 VGA 出現為止，才大致成為現今我們所看到的樣貌。VGA 全名是 Video Graphics Array，VGA BIOS 也相容於之前的 CGA/EGA。 CGA - Color Graphics Adapter EGA - Enhanced Graphics Adapter VGA BIOS 透過 INT10H (10 號中斷) 來提供 DOS 程式在瑩幕上畫圖，以前學過 x86 assembly 的朋友一定都知道這號有名的中斷。標準的 VGA BIOS 提供以下的功能： * CGA/EGA/VGA routines, INT 10H - 功能編號 00h~0Fh * EGA/VGA routines, INT 10H - 功能編號 10h~13h * VGA routines, INT 10H - 功能編號 1Ah~1Ch * 標準的 VGA 參數表與字型表 另外，常常聽到的 "VESA" 全名是 Video Electronics Standards Association，這是一個制定 VGA BIOS Extensions 的組織，目前有主要的二份規格: VBE 2.0 (1994) 與 VBE 3.0 (1998)。VBE 制定現在耳熟能詳的 virtual screen areas 與 framebuffer 功能，像是 Linux 的 VESA Framebuffer driver (linux/drivers/video/vesafb.c) 便是能支援 VBE 2.0 compliant 的顯示卡 (因此 vesafb.c 是 x86 平台才能用的)。 以下是在網路上找到的 10 號中斷說明: http://home.educities.edu.tw/wanker742126/asm/ap07.html http://www.bookcase.com/library/dos/ints/int10.html 跟 x86 assembly 有關的: http://www.csn.ul.ie/~darkstar/assembler/ http://burks.bton.ac.uk/burks/language/asm/asmtut/asm1.htm#toc x86 中斷表 Ralf Brown's Interrupt List 這個實在是太有名了，就不多做介紹了，這位老兄整理的中斷服務表是以前寫 MS-DOS assembly 的寶典，以前還記得這份列表的最新更新都只透過 Fido Net 在散佈，所以以往 Dailup-BBS 的時代要找到這份列表都要去找台灣 Fido Net 的站台才下載得到。 現在這份列表已經可以由 WWW 很方便的下載了。下載的網址是http://www.cs.cmu.edu/afs/cs/user/ralf/pub/WWW/files.html LinuxBIOS v.s. x86 VGA 這算是比較古老的議題了，而且也是屬於實作面的問題。 把 VGA 卡插到 PowerPC 平臺上後，當然是，不會動的！VGA BIOS code 要能在 RISC 平臺上執行，必須要有 x86 emulator，由於 VGA BIOS 是 INT 10H 中斷服務，所以除了能能模擬 x86 外 (instruction set)，對於 INT 10H 與其它中斷的模擬也是必要的；另外就是 x86 上的 I/O port 要對應到 I/O memory。 LinuxBIOS 提供的 FreeVGA (Architecture Independent Video Graphics Initialization for LinuxBIOS) 應該是 x86 VGA 解決方案的第一選擇。不過我們以前的專案在摸擬 VGA 時，用的是 U-Boot + x86emu，在這裡我們使用的 x86emu 是 SciTech 的版本，目前只能由 SciTech SNAP SDK 取得。使用 U-Boot + SciTech x86emu 是第二選擇，也是我們用的方法。]]> https://www.jollen.org/blog/2006/09/vga_video_graphics_array.html https://www.jollen.org/blog/2006/09/vga_video_graphics_array.html U-Boot , ARM9 and Pre-OS 相關 Mon, 25 Sep 2006 23:21:15 +0800 Embedded Linux Distribution 比如像是 Debian for ARM 這類型的 pre-built Linux distribution for embedded Linux 其實是不太實用的，除了 large-scale 的應用或是教學用途 (eg. PeeWeeLinux) 外，實務上並不是很經常使用這個方法。 Hand-made 就是純手工打造法啦！ 在網路上 (特別是大陸網站下載的文件) 有很高的比率都是介紹如何採用 "hand-made" 的方式來建立 (bottom-up) root filesystem，不過這種方式雖然未來非常有可能不會再使用，但是絕對100%有必要去學習，幾個理由不外乎是： (1) 透過 hand-make (aka Linux from scratch) 才能了解最根本的觀念。 (2) 透過 hand-make 學習到整體性的 embedded Linux 設計流程與方法。 (3) 能更深入學到建立 embedded Linux 系統的技巧。 (4) 練功。 (5) 練就建立 embedded Linux 系統的基本功，並學習所要具備的 Linux 系統管理能力。 (*6) very critical 的問題都要 hand-make 才得以解決。 這個方法是必學的，因為可以學到很深入的 cross-compilation 技巧，比如像是在 Jollen 課程裡提到的在某些類型的套件 "porting" 方式中，就要去修改 configure.in。 Build System 像是 Jollen 設計的「教具」Jollen-Kit! Builder 就是屬於這種類似，我們的 embedded Linux 課程是希望同學建立基本功，因此是由 hand-made 教起，課程的尾巴我們給同學 Jollen-Kit! Builder，並講解如何「有效率且系統化的做 cross compilation 與建立 root filesystem」。 Build system 大多建立在 Makefile 與 script 的體系之上，幾個知名的 build system，像是 uclibc-distribution、SnapGear、Buildroot (也經常被用來建立 arm-uclibc 的 toolchain) 等，都算是 build system。 Metadata Build System 這是一種更先進高階的 "build system"，以往我們都用 Makefiel / script 來建立 build system，但這種方法 (傳統 build system) 的缺點是： (1) 無法有效解決套件間的相依 (dependency) 問題。 (2) 支援多平臺 (architecture) 時，很麻煩的！ (3) 有時改 configure.in 改到頭痛！ (4) 甚致要把套件 (package) 的 source code 也一起打包，不能設計成網路下載 (像 cflinux 這樣)。 (5) ...還有很多很多... 目前最具代表性 (也找不到別人了) 的專案是 OpenEmbedded，我們在今年初開始試著用 OpenEmbedded 來建立 embedded Linux，雖然還有不足的地方 (有時沒有比 build system 方便)，但是基本上 OpenEmbedded 已經完整展示了先進的 "Linux distribution for embedded system" 做法。 OpenEmbedded 採用 BitBake 來做套件的 cross compilation 與管理，BitBake 使用 .bb files 與 bbclass 來建立 Linux distribution。BItBake 的精神與觀念真的非常值得讚許，如果您曾經玩過 cflinux 或類似的 build system，一定會對 BitBake 與 OpenEmbedded 感到驚奇的。 雖然我們目前用 BitBake 來建立 metadata build system 還算小有收獲 (Jollen-Kit! Builder Enterprise)，不過要讓大家都能很上手的深入 OpenEmbedded 系統去做客製化、修改或是加入套件，還是有點障礙的，畢竟這不像我們上課介紹的做法那麼直覺。 而且還要挑戰 GNU autoconf，這是一大惡夢呀。 學習旅途 Embedded Linux Distribution -> Hand-made -> Build system -> Metadata build system -> 玩家! 不過不一定每個階段都要去涉獵，有些對 Linux 系統很熟的玩家級同學，甚致直接切入 build system 的修改。 最後要來 push 一下 = =" 假設對 Jollen 的課程有興趣的話，請務必了解一下我們的課程規劃，或是使用 Email 由我們提供1-by-1的咨詢，才不會花冤枉錢。 ]]> https://www.jollen.org/blog/2006/09/embedded_linux.html https://www.jollen.org/blog/2006/09/embedded_linux.html Embedded Linux: Platforms and Applications Fri, 22 Sep 2006 22:59:17 +0800 monotone 首頁節錄官方的摘要說明如下： monotone is a free distributed version control system. it provides a simple, single-file transactional version store, with fully disconnected operation and an efficient peer-to-peer synchronization protocol. SVN 是廣為使用的版本控管系統，並將取代 CVS。然而 SVN/CVS 的操作與管理的學習成本是挺高的，我們無法「勸導」客戶積極地配合我們的 CVS 模式來跟我們的程式碼同步，還好 monotone 可以代替原本 CVS 的角色 (版本控制)，並提供更簡便的版本控管機制給「朋友」或「客戶」。 Monotone 將所有不同版本的程式碼建成「一個資料庫」，附檔名是 *.mtn，比如我把 Jollen-Kit! Builder 利用 monotone 成立一個專案 (project) 並建立 jkbuilder.mtn 資料庫，那麼我只要把 jkbuilder.mtn 遞交給朋友，我朋友就可以利用 monotone 把 jkbuilder.mtn 裡的程式碼 "check out" 出來。 Monotone 用在教育訓練也是很適合的，我們現在把一大堆課程的東西都「打包」成 *.mtn，同學只要下載 *.mtn 資料回去，就可以把課程的資料 (範例、文件與套件等) 都取出來。相當的方便，monotone 可以在某些場合取代 CVS 的使用，提供大家做參考。 比如我朋友 Andrew 拿到 jkbuilder-0928.mtn 後，要先用 mtn 做 "checkout" 的動作，這時 Andrew 下達的指令會是： linux$ mtn --db=./jkbuilder-0928.mtn co --branch=org.jollen.dev 執行後，Andrew 就可以在 "org.jollen.dev/" 目錄下看到 checkout 出來的程式碼。Andrew 很熱血的幫我們改掉一下錯誤 (bug) 了！那我只要給 Andrew 一個簽證 (key)，他就可以做 "commit" 的動作。]]> https://www.jollen.org/blog/2006/09/_monotone.html https://www.jollen.org/blog/2006/09/_monotone.html GNU Toolchains & Linux Systems Programming Thu, 21 Sep 2006 22:57:50 +0800 read) 是 "共用" 的，例如 major number 相同的 device file (minor number 不同) 是共用同一塊 code，所以必須考量程式碼的「可重覆進入」寫法 (thinking about filp->private data)。 這也是為什麼在 Jollen 的 Linux 驅動程式課程裡，我們如此這般在強調 Reentrant Code (Reentrant Function) 這個主題，也花了許多時間介紹 Linux 驅動程式的 "reentrant" 觀念。 Linux 驅動程式有許多主題是一點點搞不懂，就會全盤皆不懂的，reentrant code 的觀念是其中之一。由於許多學員對於 reentrant code 的理論不甚了解，因此建議未來要來上課的同學可以事先研讀這篇寫的相當好的文章： http://www.unet.univie.ac.at/aix/aixprggd/genprogc/writing_reentrant_thread_safe_code.htm 在 Jollen 多年的 Linux 驅動程式授課經驗中，reentrant code 是同學比較不容易搞清楚的觀念，可是卻也是一開始我們課程就會講到的主題；我們提到當上層 callback 下層的驅動程式時，什麼條件下下層必考慮可重覆進入的問題。要學好 Linux 驅動程式，建議無論如何也要搞懂這個主題！]]> https://www.jollen.org/blog/2006/09/_reentrant_code_program.html https://www.jollen.org/blog/2006/09/_reentrant_code_program.html GNU Toolchains & Linux Systems Programming Wed, 20 Sep 2006 22:12:11 +0800 a web application framework in an embedded Linux system"，這是8月份在LinuxDevices.com的一篇文章介紹的題目。Web-application或者是"Application Web化"是近幾年來非常明顯的一個趨勢，思考 Embedded System 的 Web Application (Embedded Web Applications ?) 是一個頗為有趣的主題，也有許多的 paper 在討論這個題目。 目前嵌入式Linux上的web application與desktop (PC) 的web application並無太大差異，許多文件也是只以"embedded web server"做為核心的出發點，這篇在linuxdevices.com上看到的文章也是。不過這篇文章倒值得對這個題目有興趣的朋友一讀。 作者開場白就點出了這個題目的主軸: As devices are increasingly more networked, an embedded web server is becoming a standard way for users to interact with and configure an embedded device using a standard web browser. 對於web application in an embedded linux system的研究範疇，就 Jollen 目前的認知來講，可以分成幾個層級來探討： (1) 低階做法：設計一個 "monolithic" 應用程式來處理 HTTP 並輸出 HTML，例如在 Jollen 的 "Embedded Linux 嵌入式系統原理與實務 ,3e" 書上給的 web.c (a dirty embedded web server) 範例。 (2) 中階做法：建構 embedded web server 的 root filesystem，例如加入 thttpd 的使用，如此一來便能透過 CGI 規範來設計 web application；thttpd 的 CGI 大多以 C 語言撰寫。 (3) 高階做法：建構 "framework" 來設計與實作 web application，linuxdevices.com 上的這篇文章就是在討論這種做法。 實作上，要建構 "web appication framework" 的基礎平臺 (aka root filesystem)，能選擇的 open source 解決方案其實很多 (各種排列組合)；不過 Jollen 把此文作者建議的 "components" for web appication framework 實際 build 後，發現還真的不賴說，大家可以試試！以下是該作者建議的 solution： 1. Web Server: Cherokee (1MiB) 2. Model: SQLite (290KB) 3. View: Clearsilver (170KB) 4. Controller: Python (2-3MB) 看到 Model/View/Controller 了！這就是 "framework" 的重點－以MVC模式設計與實作web applications！ Figure-source (引用自): linuxdevices.com, http://www.linuxdevices.com/articles/AT5550934609.html. 這個Cherokee也是一個open source的embedded web server，試用後覺得還不賴，可以列入 thttpd/boa外的其它選擇。Cherokee還真的挺強大的，讚讚讚，列入10月份Jollen-Kit! Builder Training Edition的更新roadmap，與所有學員分享！ 節錄 Cherokee 的介紹： Cherokee is a very fast, flexible and easy to configure Web Server. It supports the widespread technologies nowadays: FastCGI, SCGI, PHP, CGI, TLS and SSL encrypted connections, Virtual hosts, Authentication, on the fly encoding, Apache compatible log files, and much more. 目前 Jollen 把基本的環境 build 好了，10月份的Jollen-Kit! Builder Training Edition也會加入，目前則是還在拼湊demo架構 (應用程式) 中。因為 Python 初學中，程式寫的哩哩辣辣的 (why not PHP >_<")。 * "Must enable us to implement a clean MVC type architecture," I think this is good. * "Must support a high level language like python for rapid development," Good but I'd like to think more.]]> https://www.jollen.org/blog/2006/09/linuxweb_application_framework_1.html https://www.jollen.org/blog/2006/09/linuxweb_application_framework_1.html Embedded Linux: Platforms and Applications Tue, 19 Sep 2006 21:37:37 +0800 net/eth.c:eth_initialize() 這是重要的 Networking 初始化的核心層，在這裡加入 int eth_initialize(bd_t *bis) {     char enetvar[32], env_enetaddr[6];     int i, eth_number = 0;     char *tmp, *end;     eth_devices = NULL;     eth_current = NULL; #if defined(CONFIG_MII) || (CONFIG_COMMANDS & CFG_CMD_MII)     miiphy_init(); #endif     ... #ifdef CONFIG_DB64360     mv6436x_eth_initialize(bis); #endif     ... #if defined(CONFIG_PPC750GIGE)     ppc750_eth_initialize(bis); #endif     ... } 在這裡可以看到很多 driver 的定義 (CONFIG_*)，我們在最後加上自己板子的 driver 定義。ppc750_eth_initialize() 是 BSP code，所以必須實作到 board 的目錄裡面。然後在 board/xxx/實作 PHY 的 driver，因為是 BSP code，依架 U-Boot 的習慣，我們必須把 PHY 的 driver 放在 board 目錄下。 實作 ppc750_eth_initialize() 接下來的重要工作，當然就是實作 ppc750_eth_initialize()，U-Boot 在開機時，會呼叫我們 PHY driver 的進入點，而這個進入點函數就叫 ppc750_eth_initialize()，U-Boot 底下的網路卡 driver 基本架構大致雷同。以下的程式碼就是我們板子的 PHY driver 進入點： int ppc750_eth_initialize(bd_t *bis) // called from eth.c:eth_initialize() {     struct eth_device *dev[MAX_NUM_ETH_PORTS]; // ethernet device 的結構     int i;     printf("Initializing ethernet ports!\n");     for (i = 0; i < MAX_NUM_ETH_PORTS; i++)     {         if (dev[i] == NULL) {         dev[i] = (struct eth_device *)malloc(sizeof(struct eth_device));     }          /* 這裡是最重要的啦，要填寫 init, halt, send, recv 四個動作 (operation) 的實作函數，大家可以看一下 struct eth_device 的原型         */         dev[i]->init = ppc750_ether_init; // 下達網路命令時，會先呼叫 init。         dev[i]->halt = ppc750_stop_ethernet; // 把網路關閉時回呼的。         dev[i]->send = ppc750_send_packet; //網路命令要送出封包時回呼的。         dev[i]->recv = ppc750_poll; // 要接收封包時回呼的。         eth_register(dev[i]); // 註冊 ethernet device 到 U-Boot 核心層     }     return i; } 到這裡是 U-Boot 提供給網路卡 driver 的架構，接著當然就是要實作 init, halt, send, recv 這四個 operation 了！底層 Driver 的 operation 是跟硬體相關的，也就是看 datasheet 寫 driver 的工作！ ]]> https://www.jollen.org/blog/2006/09/uboot_driver.html https://www.jollen.org/blog/2006/09/uboot_driver.html U-Boot , ARM9 and Pre-OS 相關 Mon, 18 Sep 2006 17:35:32 +0800 Yellow Dog Linux、Red Hat Linux for PowerPC 與 Debian PPC (或 Ubuntu PPC)；Jollen 的話是選擇用 Debian PPC。 (3) NFS root filesystem 可以用 busybox，不過建議是 porting 完整的 init 與 mount，因此需要下載 sysvinit 與 util-linux 二個套件。 (4) 要 mount NFS 的話，target 端最好要有 portmap daemon，以加速 NFS mount，也才不會出現「portmap: NFS server local not responding」之類的訊息。（建議是一定要裝啦） 其它該注意的小地方也給大家分享一下： (1) 網路上可以教到 NFS mount 的做法有二種，一種是傳遞 "nfsroot" 參數給 kernel，由 kernel 去 mount，另一種是 build 一個 "NFS root filesystem"，然後用 fstab (也就是 mount) 去做，不過 Jollen 的建議是後者。有一些網路的文件也是建議後者。 (2) portmap 需要 tcp_wrapper 套件，記得一併下載。 (3) IP 的設定建議在開機時由 kernel 去做，不要開完機後再用 ifconfig 去設定。 提供這二天建的 NFS root filesystem for PowerPC 給大家參考，檔案要由 forum 下載。基本上，使用下列套件來 build root filesystem 就能做出一個簡單的 NFS rootfs 了 (這是 Jollen 使用的套件版本)： * busybox 1.1.3 (關掉內建的 mount / unmount) * util-linux 2.12r * tcp_wrapper 7.6 (for NFS mount) * portmap_4 (for NFS mount) 我們的板子採用 U-Boot 來做開機程式。記得要在 U-Boot 下設定 kernel command line，把 NFS 的設定加上去才行。以下 Jollen 設定 kernel 的開機參數（'ip='用來做Kernel Mode IP Configuration）： u-boot> set bootargs console=ttyS0,115200 root=/dev/ram0 ramdisk=8192 netconsole=6665@10.100.10.12/eth0,6666@10.100.10.20/ ip=10.100.10.12:10.100.10.20:10.100.10.254:255.0.0.0:ppc:eth0 'netconsole=' 的話可有可無，加上去的話可以配合 netcat 來看到 "console" 畫面。這是我們的 PowerPC 板子用的開機指令： u-boot> tftp 1000000 uImage; tftp 1200000 urootfs_ppc.img; bootm 1000000 1200000 開機後進入 Linux 命令模式後，再用 mount 把 NFS server 的目錄 mount 即可，由於我們用的 kernel 是 2.6，因此是用 'switch_root' 指令來變更 root 目錄，而不是用 "chroot"。 ]]> https://www.jollen.org/blog/2006/09/_powerpc_powerpc.html https://www.jollen.org/blog/2006/09/_powerpc_powerpc.html U-Boot , ARM9 and Pre-OS 相關 Sat, 16 Sep 2006 01:02:02 +0800 作者／陳俊宏
www.jollen.org



TIP fops所指的driver function其實是被Linux kernel所「回呼」（callback）。 Linux驅動程式將fops「註冊」至kernel裡後，並不是被user application直接呼叫，而是透過system call interface，因此fops所指的函數應是被kernel回呼。 Callback的機制有一個好處是，當函數被呼叫時，表示此時系統符合該函數被回呼的條件。因此，driver function可以預期自己是在符合一些條件的環境下執行。Callback機制另一個特點是，Linux kernel會傳遞「適當」的參數給driver function，driver function可以直接使用所接收的參數資料。

這張圖是範例 (debug card 0.1.1) 的執行圖 (Execute Flow/Path)，如果您能根據範例程式清楚地說明此圖，表示您已經掌握最主要的 Linux 驅動程式觀念了！

]]> https://www.jollen.org/blog/2006/05/linux_7.html https://www.jollen.org/blog/2006/05/linux_7.html Linux Device Drivers & Kernel Thu, 04 May 2006 10:27:24 +0800 接續前文的實作，繼續完成 physical device driver 部份；由於 physical device driver 與 I/O 存取密切相關，因此我們會先說明 Linux 的 I/O 存取函數。

作者／陳俊宏
www.jollen.org

I/O 存取的觀念

I/O device必須透過I/O port來存取與控制，每個I/O port都會被指定一個memory address，稱為I/O port address（或port address），此即所謂的memory mapped I/O。

memory mapped I/O的意義為，我們可以透過I/O port被指定的memory address來存取I/O device，如此可將複雜的I/O device存取變成簡單的memory存取，也不需要使用 assembly 來存取 I/O device。

Memory-mapped I/O的觀念是將I/O port或I/O memory “mapping” 到 memory address上，此位址稱為I/O port address。採用memory-mapped I/O觀念的主要好處是可以將I/O device的存取變成記憶體存取。因此，對使用者而言，存取I/O裝置就會變成跟CPU的記憶體存取一樣。

RISC 架構的處理器，在 system design 方面，也都採取 memory-mapped I/O (I/O memory) 的觀念。

Linux I/O Port 存取介面

在 x86 平臺上，I/O port與I/O memory可以看成是一樣的東西。但在學習Linux驅動程式實作時，則是要把二者清楚的分開來。若是要存取I/O port，Linux提供以下的I/O port存取介面：

˙ unsigned inb(unsigned port);
˙ unsigned inw(unsigned port);
˙ unsigned inl(unsigned port);
˙ void outb(unsigned char byte, unsigned port);
˙ void outw(unsigned short word, unsigned port);
˙ void outl(unsigned long word, unsigned port);

若是要存取I/O “memory”，則改用以下函數：

˙ unsigned readb(unsigned port);
˙ unsigned readw(unsigned port);
˙ unsigned readl(unsigned port);
˙ void writeb(unsigned char byte, unsigned port);
˙ void writew(unsigned short word, unsigned port);
˙ void writel(unsigned long word, unsigned port);

inb()表示要由I/O port address讀取1 byte的資料，outw()表示要輸出1 short word（2 bytes）的資料到指定的I/O port address；同理，readl()表示要由I/O memory address讀取1 long word（4 bytes）的資料，其它函數則依此類推。

範例透過I/O port 80H與debug card溝通，因此只要執行：

outb(num, 0x80);

即可將數字”num”顯示在debug card上。有些debug card的規格也支援其它的I/O port位址，若要輸出到其它I/O port位址做測試，請自行修改範例。

在未學習ioremap()函數前，我們的範例都會以直接存取I/O port的方式來設計。但Linux device driver是「不能直接」存取I/O port或I/O memory的，必須將I/O port或I/O memory “remapping” 到kernel virtual address後才能存取裝置。 此觀念在學習 PCI 驅動程式設計時便能看到。

完成我們的範例

了解 Linux 驅動程式如存取 I/O device 後，我們就可以完成 ops->write 實作了！以下是我們的實作程式碼：

unsigned long IOPort = 0x80;
void write_card(unsigned int num)
{
	MSG("write 0x%02X (%d) to debug card", (unsigned char)num, num);
	outb((unsigned char)num, IOPort);
}
ssize_t card_write(struct file *filp, const char *buff, 
		size_t count, loff_t *offp)
{
	char *str;
	unsigned int num;
	int i;

	if (count == 0) return 0;

	filp->private_data = (char *)kmalloc(64, GFP_KERNEL);
	str = filp->private_data;

	if (copy_from_user(str, buff, count))
		return -EFAULT;

	/* atoi() */
	num = str[0]-'0'; for (i = 1; i < count; i++) {
		num = num*10 + (str[i]-'0');
	}

	write_card(num);

	return 1;
};

完整範例列表

/*
 *  Debug Card 0.1.1 - Port 80 Debug Card Driver
 *
 *  Copyright (C) 2004 www.jollen.org
 *
 *  This file may be redistributed under the terms of the GNU Public
 *  License.
 */

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>

#include <linux/config.h>
#include <linux/ioport.h>
#include <linux/errno.h>
#include <linux/sched.h>
#include <linux/mm.h>
#include <asm/io.h>
#include <asm/uaccess.h>
#include "card.h"

unsigned long IOPort = 0x80;

int card_release(struct inode *, struct file *);
int card_open(struct inode *, struct file *);
int card_ioctl(struct inode *, struct file *,
	  unsigned int, unsigned long);
ssize_t card_write(struct file *, const char *, 
		size_t, loff_t *);

void write_card(unsigned int);

void write_card(unsigned int num)
{
	MSG("write 0x%02X (%d) to debug card", (unsigned char)num, num);
	outb((unsigned char)num, IOPort);
}

int card_ioctl(struct inode *inode, struct file *filp,
	  unsigned int cmd, unsigned long arg)
{
	switch (cmd) {
		case IOCTL_RESET:
			write_card(0x00);
			break;
		default:
			return -1;
	}
    	return 0;
}

ssize_t card_write(struct file *filp, const char *buff, 
		size_t count, loff_t *offp)
{
	char *str;
	unsigned int num;
	int i;

	if (count == 0) return 0;

	filp->private_data = (char *)kmalloc(64, GFP_KERNEL);
	str = filp->private_data;

	if (copy_from_user(str, buff, count))
		return -EFAULT;

	/* atoi() */
	num = str[0]-'0'; for (i = 1; i < count; i++) {
		num = num*10 + (str[i]-'0');
	}

	write_card(num);

	return 1;
};

/**************************************************/

struct file_operations card_fops = {
	open:		card_open,
	write:		card_write,
	release:	card_release,
	ioctl:		card_ioctl,
}; 

int card_release(struct inode *inode, struct file *filp)
{
	MOD_DEC_USE_COUNT;
	kfree(filp->private_data);

	return 0;
};

int card_open(struct inode *inode, struct file *filp)
{
	MOD_INC_USE_COUNT;
	return 0;
};

int init_module(void)
{
	MSG("DEBUG CARD v0.1.1");
	MSG("  Copyright (C) 2004 www.jollen.org");

	if (register_chrdev(DEV_MAJOR, DEV_NAME, &card_fops) < 0) {
		MSG("Couldn't register a device.");
		return -1;
	}
    
	return 0;
}

void cleanup_module(void)
{
    if (unregister_chrdev(DEV_MAJOR, DEV_NAME))
	MSG("failed to unregister driver");
    else
	MSG("driver un-installed\n");
}

MODULE_LICENSE("GPL");
MODULE_AUTHOR("www.jollen.org");

// card.h
#ifndef _CARD_H_

#define MSG(format, arg...) printk(KERN_INFO "DEBUG CARD: " format "\n", ## arg)

#include <linux/ioctl.h>

#define	DEV_MAJOR	121
#define	DEV_NAME	"debug"
#define DEV_IOCTLID	0xD0

#define	IOCTL_WRITE	_IOW(DEV_IOCTLID, 10, int)
#define	IOCTL_RESET	_IOW(DEV_IOCTLID, 0, int)

#endif

寫 User Program 來測試

/*
 *  Debug Card 0.1.1 - Port 80 Debug Card 'User-Space' Driver
 *
 *  Copyright (C) 2004 www.jollen.org
 *
 *  This file may be redistributed under the terms of the GNU Public
 *  License.
 */

#include <stdio.h>
#include <unistd.h>

#include <fcntl.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include "card.h"

int main(int argc, char *argv[])
{
    int devfd;
    unsigned int num = 0;

    if (argc == 1) argv[1] = "0";

    devfd = open("/dev/debug", O_RDWR);
    if (devfd == -1) {
	printf("Can't open /dev/debug\n");
	return -1;
    }

    printf("Resetting debug card...\n");
    ioctl(devfd, IOCTL_RESET, NULL);
    printf("Done. Wait 1 second...\n");
    sleep(1);

    printf("Writing %s...\n", argv[1]);
    write(devfd, argv[1], strlen(argv[1]));
    printf("Done.\n");

    close(devfd);

    return 0;
}

觀念大考驗

到這裡為止，我們已經完成階段性任務了--了解 Linux 驅動程式的架構觀念。

下一篇文章，我們會具體描繪出此範例的執行流程路徑；透過這張圖，大家便能考驗自己是否已經了解主要的驅動程式架構觀念了！

]]> https://www.jollen.org/blog/2006/05/linux_6_physical_device_driver_1.html https://www.jollen.org/blog/2006/05/linux_6_physical_device_driver_1.html Linux Device Drivers & Kernel Thu, 04 May 2006 10:18:26 +0800 根據Linux驅動程式的一般化設計流程，我們來設計一個真正可以動的驅動程式。

作者／陳俊宏
www.jollen.org

根據流程寫程式

定義 file_operations

struct file_operations card_fops = {
	open:		card_open,
	write:		card_write,
	release:	card_release,
	ioctl:		card_ioctl,
};

由此定義可以，我們所計的驅動程式將提供 open/write/close(release)/ioctl 4 個 system call 介面給 user application。

實作 System Call

接著要實作我們所提供的4個 system call。open/close(即 release)/read/write/ ioctl 是初學 Linux 驅動程式最重要的 5 個 system call，了解如何實作不同的 system call，是學好 Linux 驅動程式的重要工作。

本文先介紹 open/close(release)/write 的實作。此部份說明如後。

註冊 Driver

將driver自己「註冊」到kernel的VFS層，註冊時所要呼叫的函數根據裝置類型的不同而不同。

將驅動程式「註冊」（registration）至kernel的動作必須在init_module()函數裡實作。根據裝置類型的不同，所呼叫的函數也不同，以下是幾個基本的裝置註冊函數：

˙ int register_chrdev(unsigned int major, const char * name, struct file_operations *fops)：註冊字元型驅動程式。
˙ int register_blkdev(unsigned int major, const char *name, struct file_operations *fops)：註冊區塊型驅動程式。
˙ int usb_register(struct usb_driver *new_driver)：註冊USB驅動程式。
˙ int pci_register_driver(struct pci_driver *)：註冊PCI驅動程式。

本文範例註冊驅動程式的程式片斷如下：

#define	DEV_MAJOR	121
#define	DEV_NAME	"debug"	
#define MSG(format, arg...) printk(KERN_INFO "DEBUG CARD: " format "\n", ## arg)

int init_module(void)
{
	MSG("DEBUG CARD v0.1.1");
	MSG("  Copyright (C) 2004 www.jollen.org");

	if (register_chrdev(DEV_MAJOR, DEV_NAME, &card_fops) < 0) {
		MSG("Couldn't register a device.");
		return -1;
	}
    
	return 0;
}

register_chrdev()參數說明如下：

˙ 第1個參數：為device file的major number。該device file應在Linux系統底下以root身份手動建立。
˙ 第2個參數：
˙ 第3個參數：為驅動程式的fops。

註冊的動作是寫在init_module()裡，因此當使用者執行insmod載入驅動程式時，register_chrdev()便會執行。由此可知，註冊驅動程式的時機為insmod時。相對的，在rmmod時，必須執行解除註冊的動作，此動作必須實作在cleanup_module()函數裡。

前面所介紹的4個註冊函數，其相對應的解除註冊函數如下：

˙ int unregister_chrdev(unsigned int major, const char * name) ：解除註冊字元型驅動程式。
˙ int unregister_blkdev(unsigned int major, const char *name) ：解除註冊區塊型驅動程式。
˙ void usb_deregister(struct usb_driver *driver)：解除註冊USB驅動程式。
˙ pci_unregister_driver(struct pci_driver *drv) ：解除註冊PCI驅動程式。

範例debug card 0.1.0解除註冊的程式片斷如下：

void cleanup_module(void)
{
    if (unregister_chrdev(DEV_MAJOR, DEV_NAME))
	MSG("failed to unregister driver");
    else
	MSG("driver un-installed\n");
}

Linux驅動程式的「註冊」是一個非常重要的動作，這個動作代表 Linux 驅動程式是一個嚴謹的分層式架構；換句話說， Linux驅動程式的分層（layered）關係可透過「註冊」的程序來分析。

定義chipset標頭檔

我們所要設計的 Port 80H 除錯卡驅動程式，不需要定義標頭檔；此部份可參考 kernel 裡的 BTTV 驅動程式。

定義I/O wrapper function

我們所要設計的 Port 80H 除錯卡驅動程式，不需要定義 I/O wrapper function；此部份可參考 kernel 裡的 BTTV 驅動程式。

實作chipset控制函數

在我們所要設計的 Port 80H 除錯卡驅動程式中，我們是直接使用 kernel 的 I/O 介面來控制除錯卡，physiacl device driver 的部份將在下一篇文章再做說明。

open/release實作

open與release是Linux驅動程式最基本的2個system call。驅動程式應先實作此2個system call。

為了方便說明起見，本文後文將以「fops->open」表示實作open system call的driver function。其它system call亦同。

open與release system call的執行時機如下：

1. 當user application執行open()函數時，便呼叫Linux kernel的open system call，即執行fops->open。

2. 當user application執行close()函數時，便呼叫Linux kernel的close system call，即執行fops->release。

Linux驅動程式註冊至kernel時會指定device file的major number，user application便可以透過此符合此major number的device file與硬體溝通，即Linux驅動程式是透過VFS架構層與user application溝通。

file_operation是Linux驅動程式支援VFS的重要結構。學習file_operation的重要目的如下：

1. 了解每一個system call的用途。

2. 了解每一個system call的實作「原則」。

System call的實作原則即driver function所要負責處理的基本工作。學習Linux device driver的重要工作之一，便是一一了解fops裡每一個system call的實作原則，並依照實際需求來實作不同的 system call。

open System Call

以open system call為例，fops->open是在user呼叫open()函數時執行，即當user開啟driver所指定的device file時呼叫fops->open。

fops->open實作原則如下：

1. 將usage count加一（increment）
2. 檢查inode->i_rdev
3. 檢查裝置是否錯誤
4. 初始化裝置
5. 將驅動程式自己的資料結構放到filp->private_data

以下是本範例的fops->open實作：

int card_open(struct inode *inode, struct file *filp)
{
	MOD_INC_USE_COUNT;
	return 0;
};

release System Call

當user application 呼叫close() 函數後，便執行fops->release。

有些驅動程式會將release method函數名稱命名為 XXX_close()，但建議以XXX_release()名稱為主，以避免混淆。

fops->release實作原則如下：

• 將 usage count 減一。

以下是本範例的fops->release實作：

int card_release(struct inode *inode, struct file *filp)
{
	MOD_DEC_USE_COUNT;
	kfree(filp->private_data);  //reentrant code 觀念 (本文尚未說明)

	return 0;
};

]]> https://www.jollen.org/blog/2006/05/linux_5_virtual_device_driver.html https://www.jollen.org/blog/2006/05/linux_5_virtual_device_driver.html Linux Device Drivers & Kernel Thu, 04 May 2006 09:53:13 +0800 作者／陳俊宏
www.jollen.org

一般化設計流程

我們提過，依照驅動程式本身的實作，可以將 Linux 驅動程式分為 2 大部份：virtual device driver與physical device driver。



此流程為一個觀念流程，實際撰寫驅動程式時，並不會完全以這個流程來設計。但初學Linux驅動程式時，則應以此流程為主循序學習，才能理解基本的Linux驅動程式實作。

對Linux驅動程式而言，virtual device driver的重要性遠在physical device driver之上，乍聽之下這或許不太能理解，因為沒有physical device driver是無法真正驅動硬體的。但實作上，physical device driver是一成不變的程式寫法，能不能寫出好的驅動程式，關鍵是在virtual device driver的部份。

struct file_operations

struct file_operations 是 kernel 提供的一個重要資料結構，這是學習 Linux 驅動程式第一個會認識的對象，也是最重要的一個主題。

Linux 驅動程式建構在 file_operations 之上。file_operations定義驅動程式的system call與實作system call的函數，我們把file_operations任何一個部份拿出來討論的話，都能切成virtual device driver與physical device driver二個部份。

流程解說

Virtual device driver往上是為了連結Linux kernel的VFS層，physical device drvier往下是為了存取實體硬體。

Virtual Device Driver

Virtual device driver 的目的在於設計一個「機制」良好的kernel mode驅動程式，virtual device driver也必須考慮與user application的互動。實作上，則是需要善用kernel所提供的介面（interface），即kernel APIs。

Virtual device driver再分為3階段的觀念實作：

1. 定義 file_operations
2. 實作 system calls
3. 註冊 driver (VFS)

fops 是指向 file_operations 結構的指標，驅動程式呼叫 register_chrdev() 將fops註冊到 kernel 裡後，fops 便成為該 device driver 所實作的system call進入點。實作system call的函數便是透過file_operations結構來定義，我們稱實作system call的函數為driver method。

kernel 會在需要時回呼 (callback) 我們所註冊的driver method。因此，當 driver 裡的 method 被呼叫時，kernel便將傳遞參數（parameters）給 driver method，driver method可由 kernel 所傳遞進來的參數取得驅動程式資訊。

註冊driver的動作呼叫register_chrdev()函數完成，此函數接受3個參數如下：

1. major：要註冊的裝置 major number
2. name：device 名稱
3. fops：driver 的 file operation

「註冊」這個動作觀念上是將fops加到kernel的VFS層，因此user application必須透過「device file」才能呼叫到driver method。註冊這個動作的另一層涵意則是將driver method與不同的system call做「正確的對應」，當user application呼叫system call時，才能執行正確的driver method。

Physical Device Driver

Physical device driver的目的在於實作控制硬體的程式碼。Physical device driver 的設計必須隨時查閱晶片（chipsets）的 data sheet，並透過晶片的 control register 來控制裝置。

理論上，我們可以將晶片的暫存器分成3大類：

1. data registers
2. control registers
3. status registers

Data register是晶片裡用來存放資料的暫存器，control register則是用來控制晶片行為的暫存器，status register則保存目前晶片的狀態。設計控制硬體周邊的驅動程式時，需要了解硬體使用的晶片組，晶片組則需要參考IC設計廠商所提供的「datasheet」才能了解晶片組的暫存器名稱與用途，通常不同的暫存器會對應到一個「相對」的偏移位址（offset）。

驅動程式則是要透過control register才能控制晶片，因此需要隨時查閱晶片的datasheet，並了解每一個暫存器的用途。通常暫存器的每個位元（bit）也都是有特定用途的，因此設計驅動程式時，必須要很熟悉C語言的位元運算用法。

實作上，首先會將晶片的 datasheet 寫成C語言的標頭檔，通常這個檔案都可以從 vendor 取得。

接著再定義一組操作暫存器的I/O函數，我們稱這組函數為I/O wrapper function。I/O wrapper functions通常是重新定義Linux kernel所提供的readb()、writeb()或inb()、outb()系列函數所寫成的。

最後，利用I/O wrapper function實作一系列的控制函數，以控制實際硬體，我們稱此函數為chipset control functions。Chipset control functions是由實作system calls的函數（driver method）所呼叫，因此在設計chipset control functions時也會回頭改寫driver method以符合此階段的實作。

]]> https://www.jollen.org/blog/2006/05/linux_4_linux.html https://www.jollen.org/blog/2006/05/linux_4_linux.html Linux Device Drivers & Kernel Thu, 04 May 2006 09:06:23 +0800 作者／陳俊宏
www.jollen.org

什麼是 Device File

Device files 是 UNIX 系統的獨特觀念，在 UNIX 系統底下我們把外部的周邊裝置均視為一個檔案，並透過此檔案與實體硬體溝通，這樣的檔案就叫做 device files，或 special files。



Linux device driver 與 user 的重要溝通橋梁為 device files，在 Linux 系統底下，我們看到的 device files 如圖所示。檔案屬性的第一個位元如果顯示為 “c” 表示這是一個字元型裝置的 device file、若為 “b” 表示這是一個區塊型裝置的Device file。

Device file 的 major number 代表一個特定的裝置，例如 major number 為 1 為 null 虛擬裝置，major number 定義於 kernel 文件目錄 Documentation/devices.txt 。Minor number 代表裝置上的子裝置，例如同一個硬碟上的分割區就用不同的 minor number 來代表，但其 major number 相同。

Device File 與驅動程式的關係

我們在設計 device driver 時，會先透過一個 “註冊” (register) 的動作將自己註冊到 kernel 裡，註冊時，我們會指定一個 major number 參數，以指定此驅動程式所要實作的週邊裝置。當 user 開啟 device file 時，kernel 便會根據 device file 的major number 找到對應的驅動程式來回應使用者。Minor number 則是 device driver 內部所使用，kernel 並不會處理不同的 minor number。

設計 device driver 的第一個步驟就是要定義 driver 所要提供的功能 (capabilities)，當 user application 呼叫open() system call 時，kernel 就會連繫相對應的 driver 來回應使用者。

file_operations 是學習 device driver 最重要的一個資料結構，file_operations內的成員為函數指標，指向 “system call 的實作函數”。file_operations 即是圖中的 VFS 層。換句話說，Linux驅動程式是透過file_operations來建構VFS層的支援。而file_operation裡的函數指標，即是指向每一個system call的實作函數。

變更紀錄

• 2006-12-21: 勝良兄反應了一個錯誤，已修正。
]]> https://www.jollen.org/blog/2006/05/linux_3_device_file.html https://www.jollen.org/blog/2006/05/linux_3_device_file.html Linux Device Drivers & Kernel Thu, 04 May 2006 08:38:54 +0800 作者／陳俊宏
www.jollen.org

System Call 與驅動程式的關係

System call 是 user application 與 Linux device driver 的溝通介面。

User application 透過呼叫 system call 來「叫起」driver 的 task，user application 要呼叫 system call 必須呼叫 GNU C 所提供的「wrapper function」，每個 system call 都會對應到 driver 內的一個 task，此 task 即是 file_operation 函數指標所指的函數。



Linux 驅動程式與 user application 間的溝通方式是透過 system call，實際上 user application 是以 device file 與裝置驅動程式溝通。要達成此目的，驅動程式必須建構在此「file」之上，因此 Linux 驅動程式必須透過 VFS（virtual file system）層來實作 system call。

一個簡單的範例

/dev目錄下的檔案稱為device file，是 user application 用來與硬體裝置溝通的介面。以下是一個簡單的範例：

int main(int argc, char *argv[])
{
    int devfd;

    devfd = open("/dev/debug", O_RDONLY);

    if (devfd == -1) {
 printf("Can't open /dev/debug\n");
 return -1;
    }

    ioctl(devfd, IOCTL_WRITE, num);

    close(devfd);

    return 0;
}

當我們打開/dev/debug檔案時，範例所呼叫open()函數會叫起支援/dev/debug驅動程式的對應函數；同理，我們對/dev/debug執行ioctl()函數時，也會叫起驅動程式的相對應函數。

範例中的open()與ioctl()函數皆是GLIBC裡的函數，「叫起」驅動程式函數的動作涉及user space與kernel space的切換，此動作藉由system call介面來完成。設計一個支援”/dev/debug”裝置的驅動程式則是Linux驅動程式設計師所要負責的工作。

]]> https://www.jollen.org/blog/2006/05/linux_2_system_calls.html https://www.jollen.org/blog/2006/05/linux_2_system_calls.html Linux Device Drivers & Kernel Thu, 04 May 2006 08:30:52 +0800 www.jollen.org



Linux 驅動程式的大架構

Linux 驅動程式的整體架構如下：

1. application 透過 system call 介面與 kernel 溝通。
2. 透過 kernel 的 VFS 層與 Linux 驅動程式物件溝通。
3. Linux 驅動程式可分為 3 大類型，如下圖綠色部份。



Linux 驅動程式三類型

Linux device driver 可分成 3 種類型：

• character device driver
• block device driver
• network device driver

驅動程式本身可分成 2 個層面來討論：

• virtual device driver
• physical device driver

Virtual Device Driver

往上層支援 Linux kernel 所提供的 Virtual File System 層，並藉此實作 system calls。使用者可透過 system call interface 與 device driver 溝通。

Virtual device driver 的主題重要性大於 physical device driver，如何善用 Linux 所提供的介面 (interface) 來設計驅動程式，並配合 user application 來設計應用程式是這個主題的重點。與 user application 如何互動，是撰寫驅動程式時所要考慮的重要一環，只考量驅動程式本身的設計，而忽略或輕忽 user application 的設計，是錯誤的觀念。

Virtual device driver 的目的在於善用 Linux 的 APIs 來設計機制 (mechanism) 與行為 (behavior) 良好的驅動程式，因此「觀念」的重要性遠大於「語法」的討論。本書秉持這樣的信念撰寫而成，仔細閱讀絕對是多多益善的。

Physical Device Driver

往下層使用 Linux kernel 所提供的 device interface 來存取並控制實體硬體裝置。

Physical device driver 則是討論「如何透過 I/O port 或 I/O memory」來控制裝置，也就是與晶片組的溝通。這個部份需要實作晶片組的 data sheet，本書會以市面上最容易取得的 BT878 視訊擷取晶片為例做說明。

小結

學習 Linux device driver 應由 character device driver 起步，因為許多重要的入門觀念均可藉由 character device driver 學得。

OS 是設計良好的軟硬體介面，Linux 驅動程式設計即是在學習如何使用 Linux 提供的介面來設計驅動程式。

在 OS 上應使用設計良好的 API 來撰寫驅動程式，使用 OS API 的最大優點是使得驅動程式的設計抽象化 (abstraction)，我們可以不需要太深入硬體層次。

Linux kernel 所提供的 API 均經過良好設計，因此使用 kernel 所提供的 API 可以確保系統運行的安全性與穩定性。

]]> https://www.jollen.org/blog/2006/05/linux_1.html https://www.jollen.org/blog/2006/05/linux_1.html Linux Device Drivers & Kernel Thu, 04 May 2006 08:15:29 +0800 www.jollen.org



Kernel 2.4 & 2.6 編譯

底下用一個表格來比較編譯 kernel 2.4 與 kernel 2.6 的步驟差異。

Kernel 2.4	Kernel 2.6
1.編譯設定： # make menuconfig 2.編譯核心： # make dep # make bzImage 3.編譯模組並安裝： # make modules # make modules_install	1.編譯設定： # make menuconfig 2.編譯核心與模組： # make 3.安裝： # make modules_install install

Kernel 2.6 模組編譯

kernel 2.6 的模組「模組化」程度相當高，因此在 kernel 2.6 環境下編譯模組時，是以 sub-module 的觀念來實施，與 kernel 2.4 的獨立編譯觀念不同。首先，舉我們的 debug card 範例來說明編譯 kernel 2.6 模組的方式；接著再說明安裝 kernel 2.6 模組的方法。

1. 先撰寫編譯模組的 Makefile 如下：

obj-m := card.o

KDIR := /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)

default:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules

2. 編譯：

# make

編譯後可以得到 card.ko，這才是真正的 kernel 2.6 模組；kernel 2.6 模組的副檔名為 "*.ko"。

3. 將 card.ko 複制到模組目錄下：

# cp card.ko /lib/modules/`uname -r`/kernel/drivers/

4. 重新產生模組的 "dependency descriptions"：

# depmod -a

5. 安裝模組：

# insmod ./card.ko

或是：

# modprobe card

同樣是利用 insmod 或 modprobe 指令將 card.ko 安裝至系統即可。

]]> https://www.jollen.org/blog/2006/05/kernel_26.html https://www.jollen.org/blog/2006/05/kernel_26.html Linux Device Drivers & Kernel Tue, 02 May 2006 11:08:20 +0800 www.jollen.org



ifconfig 指令

ifconfig 指令是Linux網路組態設定的主要系統管理命令。以下我們說明如何手動設定這些網路組態：

• IP
• gateway
• netmask
• DNS
• broadcast

設定 IP

例如，要將系統的 IP 設定為 59.120.22.215，則執行以下命令：

linux# ifconfig eth0 59.120.22.215

同時請將 loopback device 也加上去：

linux# ifconfig lo 127.0.0.1

直接執行 'ifconfig' 不加任何參數的話，可以看到目前的網路組態設定：

eth0 Link encap:Ethernet HWaddr 00:13:D4:C4:0D:ED
inet addr:59.120.22.215 Bcast:59.120.22.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1768542 errors:0 dropped:0 overruns:0 frame:0
TX packets:2411565 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:216276166 (206.2 Mb) TX bytes:2221236364 (2118.3 Mb)


lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:453762 errors:0 dropped:0 overruns:0 frame:0
TX packets:453762 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:959840798 (915.3 Mb) TX bytes:959840798 (915.3 Mb)

lo 是所謂的 loopback 界面，eth0 就是我們剛剛設定好的乙太網路界面，有了這層界面後，才能連上 Internet。這個動作必須在成功載入網路卡的驅動程式後才能執行。

別忘了，我們還沒替 eth0 界面設定好 gateway 與broadcast。gateway 是閘訊通，正確設定閘訊通才能連接外面的網路，否則只能連接區域網路內的主機，broadcast 是廣播位址，有了這個位址才能廣播封包到區域網路內的所有主機，例如要設定 gateway 與 broadcast 分別為 59.120.22.254 與 59.120.22.255。

設定 broadcast

執行：

linux# ifconfig eth0 broadcast 59.120.22.255

再執行 ifconfig 就可以發現 eth0 的 broadcast 位址已經被改變了。

設定 Netmask

例如，要將 eth0 的 netmask 設定成 255.255.255.0，則執行：

linxu# ifconfig eth0 netmask 255.255.255.0

其它組態的設定方法

設定 Gateway

修改 Gateway 設定：

linux# route del default
linux# route add default gw 59.120.22.254

我們先刪除 default 再加入新的 gateway 位址，不過這個刪除的動作也可以省略不做。

此時我們已經加入了一個預設的 gateway，直接執行 'route' 不加任何參數，便能看到目前的 gateway 設定：

linux# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
59.120.22.0 * 255.255.255.0 U 0 0 0 eth0
169.254.0.0 * 255.255.0.0 U 0 0 0 eth0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default 59-120-22-254.H 0.0.0.0 UG 0 0 0 eth0

設定 DNS

最後要設定的是 DNS，DNS 負責 Domain Name與 IP 位址之間的轉換，例如我們打 embedded.jollen.org，經由查詢 DNS，得知其 IP 位址為 59.120.22.215，有了 IP 位址才得以和遠端的主機連線，因此正確設定一台可用的 DNS是很重要的。

設定 DNS 的方法很簡單，只要編輯 /etc/resolv.conf 即可，以下是一個範例：

search jollen.org 
nameserver 163.14.192.1   #第一個 nameserver 意同 primary DNS
nameserver 168.14.1.1     #第二個 nameserver 意同 secondary DNS

第一行是設定網域名稱搜尋，第二、三行則是設定 DNS server。search 通常用在區域網路，例如我們的主機位於 jollen.org 的網域，則設定 search jollen.org 的話，只要打主機名稱：

linux# telnet www

效果跟

linux# telnet www.jollen.org

是相同的。如果設定多個 domain 的話，則依序搜尋到一個合法的位址為止，例如：

search jollen.org xxx.com

若 telnet www 的話，會先找 www.jollen.org，如果失敗會接著找 www.xxx.com。

nameserver 是設定 DNS，這裡的 DNS 必須是 IP 位址，系統會依序向這些名稱伺服器做查詢，向第一個 DNS 做查詢若失敗，則往下向第二個 DNS 做查詢，依此類推。

/etc/hosts

我們可以把常用的 domain name 編輯到 /etc/hosts 裡，然後設定好 host.conf，如此一來當我們使用這些常用的 domain name 時就可以不必再經由 DNS 的查詢程序，進而提升速度，例如以 www.jollen.org 為例，只要在 /etc/hosts 加上：

59.120.22.215 www.jollen.org jollen

這樣一來執行 "telnet jollen" 就等於是 "telnet 59.120.22.215"。

/etc/hosts.conf

設定好 /etc/hosts 後還要檢查一下 /etc/hosts.conf 的設定，確定名稱查詢時會先查詢 /etc/hosts，請檢查 /etc/hosts.conf 是否有一行：

order hosts,bind

表示先查詢 /etc/hosts，失敗的話再向 DNS 主機查詢。

]]> https://www.jollen.org/blog/2006/04/embedded_linux_4.html https://www.jollen.org/blog/2006/04/embedded_linux_4.html Embedded Linux: Platforms and Applications Mon, 24 Apr 2006 16:20:30 +0800 www.jollen.org



/etc/rc.d/ 概念

請同學參照 Red Hat Linux 的系統檔案來閱讀本文，我們的課程實作與 Red Hat Linux 的 init script 寫法頗有差異，但研讀 Red Hat Linux 的 init script 架構可以學習到完整的 init script 概念。同時，Red Hat Linux 的 init script 也是符合 LSB 標準的做法。

/etc/rc.d/ 裡的檔案在開機時，會由 init 來執行，因此，我們可以把一些設定編輯在裡面，在開機時自動做好設定，這些文字的執行檔，我們稱它為 script，又因為是開機時會執行的 script，所以也稱為 bootup scripts。

/etc/rc.d/rc?.d/ 裡的檔案都鍊結到 /etc/rc.d/init.d/ 裡，因此，我們只要針對/etc/rc.d/init.d/ 裡的檔案來做討論即可。

init 會根據 /etc/inittab 裡的預設 run level 來執行 /etc/rc.d/rc?.d/ 目錄裡的鍊結，例如我們在 /etc/inittab 預設 run level為 3：

id:3:initdefault:

則 init 會去執行 /etc/rc.d/rc3.d/ 目錄裡的檔案，指令 telinit 可以改變系統的 run-level，例如：

linux# telinit 5

表示將系統的 run level 改變成 5，則 init 在看到 run level 的改變時，就會去執行/etc/rc.d/rc5.d/ 裡的檔案。

/etc/rc.d/rc?.d 檔案格式

/etc/rc.d/rc?.d 裡的檔案格式都具有特殊義意，例如：

S17httpd
K18httpd

"S" 表示 start，"K" 表示 stop (kill)，17 是優先序，數字低的先執行，httpd 則是表示這個檔案鍊結到 /etc/rc.d/init.d/httpd，因此 S17httpd 是「第 17 順位執行httpd」的意思，同理，K18httpd 則代表「第 18 順位關閉 httpd」，優先序是為了控制程式執行的順序，因為有一些程式會要求必須先載入一些特定程式才能執行，所以就利用優先序來控制，另外，優先序並不一定要是連續的數字，但執行時一定是由小而大執行，例如 S15httpd 執行完後，可能不會有 S16 的順序，所以就繼續往下執行。

/etc/rc.d/init.d 裡的 scripts 還提供一些參數，例如 Apache web server 的 script 為 /etc/rc.d/init.d/httpd，除了在開機時會自動被執行外，在命令模式下執行：

linux# /etc/rc.d/init.d/httpd stop

表示要終止 httpd (Apache web server) 的執行，Red Hat Linux 的 init script 實作可以讓使用者下達命令參數，此部份亦制定於 LSB 標準中。

例如，/etc/rc.d/init.d 裡的 script 提供了 6 種參數，但要注意的是，並不是所有的 script 都提供所有的參數，這 6 個參數為：

• start
• stop
• restart
• force-reload
• reload
• status

範例：

linux# /etc/rc.d/init.d/httpd restart
linux# /etc/rc.d/init.d/httpd start

這二個指令分別是重新啟動及啟動 httpd 的意思。當我們修改 Apache 的設定後，就可以下第一個命令來重新啟動 httpd，使新的設定生效。

再以一個例子說明，當我們想要關閉防火牆時，應該把 iptables 服務關閉，此時可以下達此命令：

linux# /etc/rc.d/init.d/iptables stop

]]> https://www.jollen.org/blog/2006/04/embedded_linux_3_initial_scrip.html https://www.jollen.org/blog/2006/04/embedded_linux_3_initial_scrip.html Embedded Linux: Platforms and Applications Mon, 24 Apr 2006 15:53:58 +0800 www.jollen.org



重要設定檔

為了能更了解 Linux 整個系統，學習 Linux 的第一步，必須先把幾個常用的設定檔研究一下。底下整理出幾個常用檔案。

系統管理相關設定檔

□ /etc/passwd

使用者帳號檔案。

□ /etc/shadow

儲存只有 root 才能讀取的帳號資訊，例如編碼過的密碼字串。

□ /etc/group

使用者群組檔案。

系統的定時裝置，可以讓系統在特定的時間或時間間隔執行指定的工作。

□ /etc/inittab ^{(must have!)}

設定開機時要啟動的 service 與 process。

□ /etc/fstab ^{(must have!)}

設定分割區與 mount 路徑的檔案。

□ /etc/termcap

各種不同終端機、印表機的字元定義。

網路相關設定檔

□ /etc/hosts

存放 IP 與host name 對應表。

□ /etc/hosts.allow

設定允許連線的 host。

□ /etc/hosts.deny

設定拒絕連線的 host。

□ /etc/resolv.conf

設定 DNS 主機。

□ /etc/inetd.conf

設定 inetd daemon 服務，也就是電腦所提供 TCP/IP 服務。Busybox 仍然提供舊式的 inetd 服務，Embedded Linux 較適合使用舊式的 inetd.conf 來實作。

Linux系統的檔案結構原則上應依照 Linux Standard Base 所制定的標準實作。

]]> https://www.jollen.org/blog/2006/04/embedded_linux_1.html https://www.jollen.org/blog/2006/04/embedded_linux_1.html Embedded Linux: Platforms and Applications Mon, 24 Apr 2006 15:26:08 +0800 www.jollen.org



/etc/fstab 的用途

/etc/fstab 是設定分割區與 mount 目錄關係的檔案，開機時會依這個檔案的內容 mount 檔案系統，mount 檔案系統的命令為：

linux# mount -av

會依 /etc/fstab 的內容 mount 進除了 root 以外的所有檔案系統。

root 是在開機時由核心所 mount 進來的。root 先由核心 mount 成 read-only，然後由使用者手動 remount 成 read-write。

/etc/fstab 設定格式

一個簡單的 /etc/fstab 設定範例如下：

#Device mount point filesystem type option
LABEL=/ / ext2 defaults 1 1
/dev/sda5 /home ext2 defaults 1 2
/dev/cdrom /mnt/cdrom iso9660 noauto,owner,ro 0 0
/dev/fd0 /mnt/floppy auto noauto,owner 0 0
LABEL=/usr /usr ext2 defaults 1 2
none /proc proc defaults 0 0
none /dev/pts devpts gid=5,mode=620 0 0
/dev/sda7 swap swap defaults 0 0 

每個欄位所代表的義意為：

• device 指定分割區
• mount point 指定要 mount 目錄
• filesystem type 指定檔案系統，比較常用的檔案系統有：

‧ msdos
‧ vfat
‧ nfs
‧ swap
‧ ext2

使用這些檔案系統前，請先確認核心是否支援，要知道目前核心的狀態支援那些檔案系統，可以查看 /proc/filesystems：

ext2
nodev proc

iso9660
nodev devpts
nodev usbdevfs 

表示目前核心支援 ext2/proc/iso9660/devpts/usbdevfs 的檔案格式，其中proc、devpts 與 usbdevfs 前面有一個 nodev 關鍵字，表示這二個檔案系統其實是存在記憶體中的，並非真正存在於儲存裝置中。

• option 設定參數，如果我們要 mount 的是硬碟的分割區，不管是什麼檔案系統，只要設定為 defaults 即可。
• 第一個數字，0 或者空白表示不要 dump，1 表示要 dump，dump 是用來將系統備份到磁帶機的指令，備份時，如果想要略過這個分割區，在一欄填 0 即可，如困2這一欄是 1 的話， dump 時就會備份這個分割區。
• 第二個數字，是設定當系統有不正常關機情形時，要如何檢查這些檔案系統。首先 fsck 會依序檢查這一欄為 1 的檔案系統，然後同時檢查這一欄為 2 的檔案系統，0 或者空白的話表示不做檢查。一般而言，只會將 root 設定為 1，其它都設定為 0 或 2。一些特定的檔案系統，像是 swap、iso9660、nfs、proc 都設定為0。

proc 是比較特殊的檔案系統，/proc 其實是存在於記憶體中的，/proc 裡的檔案紀錄了目前系統的狀態，藉由觀察這裡面的檔案我們可以得知許多系統的資訊。

例如，要檢查目前 swap partition 的狀態可以查看 /proc/swaps：

Filename Type Size Used Priority
/dev/sda7 partition 136512 4648 -1 

最後舉個例子，例如為電腦新增了一顆硬碟，然後切出了一個 /dev/sdb8 的 partition，並且想將這個 partition 做來做 ftp 的 home，這時就要在 /etc/fstab 裡加上一行：

/dev/sdb8 /home/ftp ext2 defaults 1 2

/etc/inittab 設定

init process

init 是在核心 mount 進 root 後，第一個執行的程式 (第一個 process)，init 所負責的工作包括：

• 執行 /etc/rc.d/rc?.d/ 裡的 scripts
• 將系統由開機狀態 (boot-up state) 切換至多使用者狀態 (multiuser state)
• 負責載入 tty (本地端) 的 login shell
• 負責開機與關機的程序 (procedure)。

開機完成後，init 仍會保持在背景執行，並同時監視與修改系統執行狀態。init 監視許多系統的動作，適時改變系統的狀態，這些動作定義在 /etc/inittab 檔案裡。系統狀態劃分成七個等級，稱之為 run level，/etc/inittab 即告訴 init，在不同的 run level 下所要執行的程式與命令，Linux 下的 run level 有共七個，分別為：

• run level 0 關機
• run level 1 單一使用者模式
• run level 2 多使用者模式(沒有NFS)
• run level 3 多使用者模式
• run level 4 保留
• run level 5 X11
• run level 6 重開機

以 Red Hat Linux 的 /etc/inittab 為例

不正確的 /etc/inittab 設會使得系統不正常，而且無法登入，所以修改 /etc/inittab 前請先做好備分，/etc/inittab 的設定如下：

#
# inittab This file describes how the INIT process should set up
# the system in a certain run-level.

#
# Author: Miquel van Smoorenburg, <miquels@drinkel.nl.mugnet.org>
# Modified for RHS Linux by Marc Ewing and Donnie Barnes

#
# Default runlevel. The runlevels used by RHS are:
# 0 - halt (Do NOT set initdefault to this)
# 1 - Single user mode
# 2 - Multiuser, without NFS (The same as 3, if you do not have networking)
# 3 - Full multiuser mode
# 4 - unused
# 5 - X11
# 6 - reboot (Do NOT set initdefault to this)

# 

id:3:initdefault:

# System initialization.

si::sysinit:/etc/rc.d/rc.sysinit


l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6



# Things to run in every runlevel.

ud::once:/sbin/update



# 處理 [ctrl]-[alt]-[del] 的按鍵
ca::ctrlaltdel:/sbin/shutdown -t3 -r now



# 如果我們有 UPS，這一行的設定會在斷電時通知我們，並在 2 分鐘後自動關機。 
pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"



# 如果在關機前恢復電力，則放棄關機。
pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"





# 用來登入系統 (本地端)。
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6



# gdm 程式。
x:5:respawn:/etc/X11/prefdm -nodaemon

每個欄位所代表的義意如下：

• 第一個欄位，是 init 內部使用的名稱，用來辨認每一個項目，執行命令 "ps ax" 所看到的名稱。
• 第二個欄位，表示這個項目的 run level。
• 第三個欄位，關鍵字欄位，其中 respawn 是一個重要的關鍵字。以 "5:2345:respawn:/sbin/mingetty tty5" 為例說明，init 會依據設定，在本地端開啟一個終端機，當這個終端機超過時間沒有人 login 或太久沒有按鍵時，這個終端機就會結束執行，respawn 即在告訴 init 再重新執行這個終端機，否則，在一段時間後，我們會發現這個終端機消失了，無法利用 [alt]-[f5] 切換終端機。
• 第四個欄位：要執行的命令與參數

第一行的 "id:3:initdefault:" 是很重要的一行，用來告訴 init，預設的 run level，在這裡我們設定開機後的預設 run level 為 3，那麼下面設定的命令都會被執行：

l3:3:wait:/etc/rc.d/rc 3

ud::once:/sbin/update
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"
pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6

第二個如果是空白，則表示在所有的 run level 都會執行，例如：

ca::ctrlaltdel:/sbin/shutdown -t3 -r now

表示在按下 [ctrl]-[alt]-[del] 的事件發生時，在所有 run level 狀態下，都會去執行/sbin/shutdown -t3 -r now 的命令。這一欄也可以指定多個 run level，例如：

6:2345:respawn:/sbin/mingetty tty6

表示在進入 run level 2/3/4/5 時，都會執行 "/sbin/mingetty tty6"。

改變 run level

如果我們將預設 run level 改為 5：

id:3:initdefault:

那麼：

x:5:respawn:/etc/X11/prefdm -nodaemon

這一行便會生效，"/etc/X11/prefdm -nodaemon" 的命令就會被執行，也就是我們熟悉的gdm。

我們可藉由 telinit 指令來改變目前的 run level，例如在 run level 3 狀態下執行：

linux# telinit 5

就會馬上進入 run level 5，執行 gdm。在 gdm 下如果想回到 console 模式，可以按下[ctrl]-[alt]-[f1]，後然再執行：

linux# telinit 3

即可。

]]> https://www.jollen.org/blog/2005/09/embedded_linux_2_etcfstab_etci.html https://www.jollen.org/blog/2005/09/embedded_linux_2_etcfstab_etci.html Embedded Linux: Platforms and Applications Sun, 04 Sep 2005 11:06:51 +0800 Copyright (c) 2005 www.jollen.org Last date: 2005/01/17 在將 Linux kernel porting 到其它的 ARM 平臺之前, 必須先取得標準 Linux kernel,然後再做 ARM Linux patch。 下載以下檔案: ftp://ftp.arm.linux.org.uk/pub/armlinux/source/kernel-patches/v2.4/patch-2.4.26-vrs1.gz ftp://ftp.nsysu.edu.tw/Linux/Kernel/linux/kernel/v2.4/linux-2.4.26.tar.bz2 安裝 Linux kernel 與 patch: # bzip2 -dc linux-2.4.26.tar.bz2 | tar xf - # mv linux-2.4.26 linux-2.4.26-vrs1 # cd linux-2.4.26-vrs1 # gzip -dc ../patch-2.4.26-vrs1.gz | patch -p1 - 本文以 KS8695 板子為實例,說明如何將 kernel 2.4.26 (vrs1) porting 到其它的 ARM 平臺。對於所有的 ARM 平臺而言,我們可以歸納出 3 個基本的 porting 流程如下: 1. 登錄一個 Machine ID 2. 編輯 config.in 設定檔與 Makefile. linux/arch/arm/config.in arch/arm/Makefile arch/arm/boot/Makefile arch/arm/mach-XXX/Makefile 3. 修改原始檔如下. arch/arm/kernel/entry-armv.S arch/arm/kernel/debug-armv.S arch/arm/mach-XXX/arch.c arch/arm/mach-XXX/irq.c arch/arm/mach-XXX/mm.c include/asm/arch/dma.h include/asm/arch/hardware.h include/asm/arch/io.h include/asm/arch/irq.h include/asm/arch/irqs.h include/asm/arch/keyboard.h include/asm/arch/memory.h include/asm/arch/param.h include/asm/arch/system.h include/asm/arch/timex.h include/asm/arch/uncompress.h include/asm/arch/vmalloc.h 以上是 porting Linux 到其它 ARM 平臺的大原則與方法。 https://www.jollen.org/blog/2005/01/linux_kernel_porting_2.html https://www.jollen.org/blog/2005/01/linux_kernel_porting_2.html Linux Device Drivers & Kernel Mon, 17 Jan 2005 16:13:20 +0800 (原文發表於 2005/01/17) 作者／陳俊宏 Copyright (c) 2005 www.jollen.org Last date: 2005/01/17 理論上，一個完整的 Embedded Linux 系統開機過程可分成 3 個階段: bootstrap loader boot loader linux kernel bootstrap loader 比較像是 PC 上的 BIOS,大部份的target device,像是evaluation board、reference board等,都是在設計板子時由廠商設計完成並提供(ship)給終端使用者(end-user)。 Boot loader 則是像 desktop Linux 上的 LILO、GRUB 等,支援 ARM 的 boot loader 像是比較知名的 RedBoot 等都可以用在 ARM 板子上,一般 boot loader 都會提供 serial port 傳輸與 MTD 支援,讓我們可以燒錄資料到 ROM (flash) 裡。本文會以KS8695 (ARM9) 板子來當例子,這張板子上的 boot loader 還支援 ethernet 傳輸,可以讓我們透過網路將資料直接燒錄到 ROM 裡面。 * 可以參考筆者所著”Embedded Linux 嵌入式系統—原理與實務 (2e),學貫”第6 章有關 Linux 在 PC (x86) 上的開機流程講解。 我們主要所要講解的部份為 linux kernel 本身的 porting。再次,就理論上,對於linux kernel本身的porting可以分為2個層面來討論: Microprocessor architecture level Board support package (BSP) level Microprocessor architecture level 主要的工作是讓 Linux kernel 能支援不同的處理器架構,例如:PowerPC、ARM、MIPS...等等。Microprocessor 又可分為 MMU 與 MMU-less 的架構,前者可使用標準的 Linux kernel 來 porting,後者可使用 uClinux 做為解決方案。Linux kernel 本身 (包含 uClinux) 對於微處理器架構方面的 porting 工作都已經完成了! 所以我們沒有可以發揮的空間,因此 BSP level 的 porting 才是目前做 kernel porting 最主要的工作。 我們以 KS8695 板子為例來做說明。Board support package 故名思義就是要修改 kernel 讓 kernel 可以支援我們所設計的板子,我們所使用的板子採用 KENDIN KS8695 SoC,這顆 SoC 是 ARM9TDMI 的架構,因此我們要先對 Linux kernel 做 ARM Linux 的 patch,讓 Linux kernel 能完整支援 ARM 微處理器。 接著,就要修改 patch 好的 Linux kernel (ARM9) 讓 kernel 可以支援 KS8695 這顆 SoC。也就是基於支援 ARM9 (armv) 的 Linux kernel 來加入 (porting) 對 KS8695 SoC 的支援,即進行 KS8695 的 board support package level porting。 針對 ARM (with MMU) 的 BSP porting 工作,是存在一個標準的操作流程的! 在本文#2中將會介紹此 porting 流程。 https://www.jollen.org/blog/2005/01/linux_kernel_porting_1_1.html https://www.jollen.org/blog/2005/01/linux_kernel_porting_1_1.html Linux Device Drivers & Kernel Mon, 17 Jan 2005 16:11:38 +0800 作者／陳俊宏 Copyright (c) 2004 www.jollen.org Last date: 2004/08/11 本文示範如何建立支援ARM9的uClibc。筆者所使用的target device為KS8695的板子,microprocessor是KENDIN的ARM9TDMI。 1. 下載uClibc-0.9.20. 因為某些原因,我們 使用0.9.20的 版本,請 不要下載其它的板本,以 免無法順利編譯。下載後的 uClibc-0.9.20 必須做小部份修改,因此 請讀者直接下載筆者修改好的uClibc。 http://www.jollen.org/EmbeddedLinux/ARM/uClibc-0.9.20-xwire.tar.gz 2. 解開uClibc後並進入設定選單: # tar zxvf uClibc-0.9.20-xwire.tar.gz # cd uClibc-0.9.20-xwire # make menuconfig 接著直接離開並儲存設定即可,筆者 修改過的版本預設值支援KS8695板子。 3. 修改 Linux kernel 路徑設定。將 .config 檔裡的 KERNEL_SOURCE 設定改到正確的 kernel 路徑: KERNEL_SOURCE="/home/xwire/linux-2.4.26-vrs1" 編譯 uClibc 時會參考到 kernel 的標頭檔,因此必須對標準的 kernel 做 ARM patch 以及 KS8695 board-specific 的 PATCH。讀者可先下載筆者提供的標頭檔套件，以順利編譯 uClibc。 4. 編譯uClibc: # make 5. 安裝uClibc的開發環境: # make install PREFIX=/usr/local/uClibc-0.9.20 6. 安裝uClibc的執行環境: # make install_target TARGET_PREFIX=/home/rootfs/lib 請將路徑指到正確的filesystem (ARM9) 路徑,由於我們開啟shared library的 功能,因 此必須安裝runtime環 境至target的filesystem裡。 https://www.jollen.org/blog/2004/08/build_uclibc_for_arm.html https://www.jollen.org/blog/2004/08/build_uclibc_for_arm.html GNU Toolchains & Linux Systems Programming Wed, 11 Aug 2004 16:10:42 +0800 作者／陳俊宏 Copyright (c) 2004 www.jollen.org Last date: 2004/08/11 1. 下載以下套件: gcc-3.4.1.tar.bz2 newlib-1.12.0.tar.gz binutils-2.15.tar.bz2 2. 解開套件: # bzip2 -dc gcc-3.4.1.tar.bz2 | tar xf - # tar zxvf newlib-1.12.0.tar.gz # bzip3 -dc binutils-2.15.tar.bz2 | tar xf - 3. 建立編譯用目錄: # mkdir build-gcc build-binutils 4. 首先編譯GNU binutils套件: # cd build-binutils # ../binutils-2.15/configure --srcdir=../binutils-2.15 --target=arm-elf --prefix=/usr/local/gnu-3.4.1 --enable-softfloat –-enable-shared # make all # make install - ARM7TDMI 與 ARM9TDMI 不支援硬體浮點運算。 - 筆者使用的 target device (KS8695P) 是 ARM9TDMI 的裝置,ARM9TDMI並沒有DSP,因此必須建立啟用軟體浮點運算功能。 - 編譯完成後可以在 /usr/local/gnu-3.4.1 目錄下找到執行檔。 5. 編譯GCC與Newlib: 一開始必須先將 newlib 放到 gcc 原始碼目錄下,才能和gcc一併編譯. # cd gcc-3.4.1 # ln -s ../newlib-1.12.0 newlib 接著設定GCC. # cd .. # cd build-gcc # ../gcc-3.4.1/configure --srcdir=../gcc-3.4.1 --target=arm-elf --prefix=/usr/local/gnu-3.4.1 --with-cpu=arm9 --with-newlib --enable-threads --with-float=soft --without-headers –-enable-languages=c GCC 3.4 必須在編譯設定時加上 “--with-float=soft|hard” 來指定要使用軟體或硬體浮點運算,在這裡我們必須指定使用軟體浮點運算。GCC 3.4 針對 ”arm-elf” 的 cross toolchains 改用由 Nicolas Pitre 所設計的ARM軟體浮點運算功能,這個新的ARM軟體浮點運算實作不但體積小而且比原來的C版本速度更快,因此請務必將target設定成arm-elf,GCC預設才會去使用新的軟體浮點運算。 執行編譯並安裝: # make all # make install 6. 最後可以在 /usr/local/gnu-3.4.1 目錄下取得完整的 Cross GNU toolchains for ARM。得到 cross toolchain 後,下一步則是要cross-compiling uClibc 或 glibc,取得C程式庫後才能開始cross-compiling應用程式。 https://www.jollen.org/blog/2004/08/_cross_gnu_toolchains_for_arm.html https://www.jollen.org/blog/2004/08/_cross_gnu_toolchains_for_arm.html GNU Toolchains & Linux Systems Programming Wed, 11 Aug 2004 16:09:40 +0800 www.jollen.org



Microwindows 的網路資源

官方網站: http://www.microwindow.org

SDK 手冊: http://embedded.centurysoftware.com/docs/nx/

入門文件 (Getting Started): http://home.twcny.rr.com/embedded/microwin/install/index.html

下載 (原始碼): ftp://microwindows.org/pub/microwindows/microwindows-0.89.tar.gz

下載 (字型, 含中文字型): ftp://microwindows.org/pub/microwindows/microwindows-fonts-0.89.tar.gz

Microwindows 簡介

分層式架構 (Layered Design)

Microwindows 是採用 3 層式架構設計，共分為 3 層：

1. lowest level - 螢幕, mouse/touchpad, keyboard 與其它硬體的 driver.
2. mid level - 可移植 (portable) 與 device-independent 的繪圖引擎 (graphics engine).
3. upper level - 提供給 programmer 的 API, 我們的程式只能呼叫 Microwindows 的 API 來繪圖.

我們所要學的就是最上層的 API, 本專欄的主要目的就是在介紹 Microwindows API 的使用方法。

Microwindows 的 Linux Driver 支援

在螢幕方面，Microwindows 支援 Linux 2.2.x 的 framebuffer，在 16-bit Embedded Linux kernel (ELKS) 也可運作。

在滑鼠方面，Microwindows 支援 GPM 與 serial port 滑鼠；另外也有 touch panel 的軀動程式。

在鍵盤方面，Microwindows 支援 tty 鍵盤讀取，在 Linux 與 ELKS 都可運作。

Hardware Device	Driver
Linux 2.2.x framebuffer	scr_fb.c fb.c fblin[1248].c
GPM Mouse	mou_gpm.c
Serial Mouse	mou_ser.c
Touch Panel	mou_tp.c
tty keyboard	kbd_tty.c

Microwindows 的 API

Microwindows 有 2 種不同的 API:

• Microwindows API
• Nano-X API

Microwindows API 與 Microsoft Win32 和 WinCE GDI 相容，因此使用 Microwindows API 的視窗系統為 message-based 的架構 (也就是 message-passing system 的視窗系統)。

Nano-X API 可以概略的比喻為小型的 X server 系統，Nano-X API 是依據 Xlib API 來設計。因此可以很直覺的了解到，利用 Nano-X API 所設計的視窗系統為 client/server 架構。

Microwindows 的優點

1. 在 PC 上支援 X，易於測試發展。

2. 針對 Embedded System 支援 framebuffer。

3. 系統小。

4. API 簡單易學。

5. 支援 TrueType fonts 字型處理。

6. 支援 ARM/MIPS/ELKS。

* ELKS 是 16-bit 的 Linux kernel

安裝 Microwindows

Microwindows 不但可以在 framebuffer 上跑，也可以在 X 上跑。一開始學 Microwindows 時，我們會先在 X 上測試，所以沒有特別說明的話之後的 Microwindows 程式都是在 X Window System 上跑 。

要讓 Microwindows 在 X 上執行，編譯前要先做一些設定：

1. 先下載 microwindows 並解開。

2. 執行 X Window System，進入圖形環境；到 microwin-0.89/src/ 執行 xconfigure。(圖 1)


圖 1：Microwindows 設定介面

3. 然後選取下面幾個項目：

Compiling options -> Optimize

Platform -> Linux (native)

Platform -> Linux (native) -> Options -> Screen driver -> X11 (再點 options 可設定解析度)

Platform -> Linux (native) -> Options -> Mouse driver -> GPM mouse (視您的滑鼠而訂)

Platform -> Linux (native) -> Options -> Keyboard driver -> TTY

I/O -> Have File I/O

I/O -> Have bmp support

I/O -> Have jpeg support

I/O -> Have freetype support (truetype fonts) (再點 options 設定路徑, 請使用 Free Type 1, Red Hat Linux 7.x 以後的使用者應設定 include dir 為 /usr/include/freetype1, 因為筆者會講到中文字型, 所以請勾選 freetype 支援)

Libraries to compile -> NanoX (本文只講 NanoX, 所以 Microwindows 不用選)

Libraries to compile -> Libraries to Shared libs (可選可不 選, 因為現階段還不會 porting 到 Embedded System, 沒什麼關係!)

Libraries to compile -> NanoX -> Options -> Enable shared mem support

Libraries to compile -> NanoX -> Options -> Compile demos (不想編譯範例的話可以不選)

4. 設定好後在 microwin-0.89/src/ 下執行 make 開始編譯。

5. 編譯好後打 make install 安裝。因為我們有勾選 shared libraries，所以可以把下面這幾個檔案殺掉 (不殺也行!):

/usr/lib/libmwdrivers.a
/usr/lib/libmwengine.a
/usr/lib/libmwfonts.a
/usr/lib/libmwobjects.a
/usr/lib/libnano-X.a
/usr/lib/libvncauth.a

6. 然後到 microwin-0.89/src/bin/ 下執行範例：

$ ./nano-X & sleep 1 (執行 Microwindows 的 nano X server)

$ ./nanowm & sleep 1 (執行 anao X server 的 Window Manager)

$ ./demo & (執行展示程式)

7. 如果可以看到這個畫面，表示 Microwindows 安裝成功。接下來就可以開始寫第一個程式了!

Nano-X API 入門 - Hello World

* 本專欄以 Nano-X API 為主，對 Microwindows API 有興趣的網友可參考官方網站的文件。

#include <stdio.h>
#include <microwin/nano-X.h>

GR_WINDOW_ID wid;
GR_GC_ID gc;

void event_handler (GR_EVENT *event);

int main (void)
{
   if (GrOpen() < 0) {
        fprintf (stderr, "GrOpen failed");
        exit (1);
   }

   gc = GrNewGC();
   GrSetGCForeground (gc, 0xFF0000);

   wid = GrNewWindowEx(GR_WM_PROPS_APPFRAME |
                       GR_WM_PROPS_CAPTION  |
                       GR_WM_PROPS_CLOSEBOX,
                       "jollen.org",
                       GR_ROOT_WINDOW_ID, 
                       0, 0, 200, 200, 0xFFFFFF);

   GrSelectEvents(wid, GR_EVENT_MASK_CLOSE_REQ | GR_EVENT_MASK_EXPOSURE);

   GrMapWindow(wid);
   GrMainLoop(event_handler);
}

void event_handler (GR_EVENT *event)
{
   switch (event->type)
   {
      case GR_EVENT_TYPE_EXPOSURE:
           GrText(wid, gc, 50, 50, "Hello World", -1, GR_TFASCII);
    break;
      case GR_EVENT_TYPE_CLOSE_REQ: 
    GrClose();
           exit (0);
      default: break;
   }
}

這是一個 Microwindows 的 Hello World 程式，編譯時要連結 nano-X 程式庫：

gcc -o hello hello.c -lnano-X

利用這個程式我們就可以測試是否能順利編譯並執行 Microwindows 系統，在執行程式前，別忘了跑 nano-X 跟nanowm 喔！


圖 2：Hello World

下一期我們將開始解說這個程式的內容，與更多的 Microwindows 程式設計。

注記

2007.01.05: 改標題，以搭配整體專欄。

]]> https://www.jollen.org/blog/2004/08/linux_microwindows_1.html https://www.jollen.org/blog/2004/08/linux_microwindows_1.html GNU Toolchains & Linux Systems Programming Wed, 11 Aug 2004 10:56:15 +0800 說在前頭

Jollen: 對於「學習」這擋事，其實我有很多自己的想法。以「學程式庫」來講，我的看法是...

學習任何一套程式庫或 application framework，絕對不是「函數導向」的學習法，也就不能以學習函數做為主軸；正確的方式應該是「主題式（subjective）」的做法，也就是由「Hello World」開始（我想這個已經成為萬年標準了！），然後由不同主題的範例來深入，由於每個主題的範例都有其目的，因此可以透過範例，將達成目的的做法學起來。

其次，每個範例一定都包含「隱含」的觀念，除了學會做法外，也要把裡頭的觀念挖出來研究，以加強能力。Jollen 在撰寫這些程式庫、程式語言與 application framework 的教學專欄時，都是用這套思考邏輯來規劃整個大綱，並且也是我自己的寫作習慣。

在這樣的學習方式與前提下，「老師不會教、學生必須自己來」的工作是：

1. 安裝（當然囉！）

2. 準備 API 手冊

3. 瀏覽 API 手冊

4. 查 API 的能力與技巧

5. 一邊看 code 一邊查 API 手冊

6. 編譯範例

7. 改範例亂玩

歡迎提供您的意見，或是不同看法讓我參考。

Nano-X 的 "Hello World"

hello.c 是我們的第一個 Nano-X 程式。在這個範例中，我們要學習基本的 Nano-X 程式設計觀念如下：

˙ GC（Graphics Context）
˙ 視窗（windows）
˙ Nano-X程式設計流程
˙ 事件處理

先看範例：hello.c

以下是 hello.c 的完整程式碼：

/*
 * Copyright(c) 2003,2004 www.jollen.org
 *
 * - Microwindows nano-X API example.
 * - hello.c
 */

#include 
#include 

GR_WINDOW_ID wid;
GR_GC_ID gc;

void event_handler (GR_EVENT *event);

int main (void)
{
   if (GrOpen() < 0) {
        fprintf (stderr, "GrOpen failed");
        return -1;
   }

   gc = GrNewGC();
   GrSetGCForeground (gc, 0xFF0000);

   wid = GrNewWindowEx(GR_WM_PROPS_APPFRAME |
                       GR_WM_PROPS_CAPTION  |
                       GR_WM_PROPS_CLOSEBOX,
                       "jollen.org",
                       GR_ROOT_WINDOW_ID, 
                       0, 0, 200, 200, 0xFFFFFF);

   GrSelectEvents(wid, GR_EVENT_MASK_CLOSE_REQ | GR_EVENT_MASK_EXPOSURE);

   GrMapWindow(wid);
   GrMainLoop(event_handler);

   return 0;
}

void event_handler (GR_EVENT *event)
{
   switch (event->type)
   {
      case GR_EVENT_TYPE_EXPOSURE:
           GrText(wid, gc, 50, 50, "Hello World", -1, GR_TFASCII);
	   break;
      case GR_EVENT_TYPE_CLOSE_REQ: 
	   GrClose();
      default: break;
   }
}

再進行觀念的強化

了解怎麼使用 Nano-X 畫出「Hello World」後，我們挑出幾個重要的觀念來做加強：

1. GC（Graphics Context）

在 Nano-X 系統裡，我們可以把 GC 視為一張畫布，透過 Nano-X 的函數我們就可以在 GC 上繪圖。呼叫 GrNewGC() 函數可以建立一個 GC，若 GC 建立成功，則 Nano-X server 會傳回一個 GC 的 ID。我們會在程式一開始的時間就建立一個 GC，程式除了可以在 GC 上繪圖外，GC 的資料也能複製或透過選取函數（selection）做區域處理。

2. 視窗（windows）

Nano-X 的視窗是在程式一開始時呼叫 GrNewWindow() 函數所建立，若建立成功則可以取得 Window ID。視窗當然具備邊框（border）與按鈕等各種視窗屬性，視窗屬性可以在視窗建立時指定，或是透過 window manager 做修改。

心得小結：Nano-X 程式設計流程

以下歸納出 Nano-X 程式設計的步驟：

1、初始化與 server 的連線。呼叫 GrOpen() 函數，若傳回小於 0 的值，表示無法與 Nano-X server 連線。程式寫法如下：

if (GrOpen() < 0) {
   fprintf (stderr, "GrOpen failed");
   return -1;
}

2、建立新的 GC：

GR_GC_ID gc;
gc = GrNewGC();

若執行成功則傳回 GC 的 ID，其資料型別為 GR_GC_ID。

3、設定 GC 的前景色：

GrSetGCForeground (gc, 0xFF0000);

指定 GC 的 ID 並設定其前景色。

4、呼叫 GrNewWindowEx() 函數建立新視窗：

GR_WINDOW_ID wid;

wid = GrNewWindowEx(GR_WM_PROPS_APPFRAME |
   GR_WM_PROPS_CAPTION |
   GR_WM_PROPS_CLOSEBOX,
   "jollen.org",
   GR_ROOT_WINDOW_ID,
   0, 0, 200, 200, 0xFFFFFF);

5、選取事件。呼叫 GrSelectEvents() 函數選擇我們想要處理的事件：

GrSelectEvents(wid, GR_EVENT_MASK_CLOSE_REQ | GR_EVENT_MASK_EXPOSURE);

以 hello.c 為例，表示我們想要處理視窗關閉請求（GR_EVENT_MASK_CLOSE_REQ）與視窗顯示（GR_EVENT_MASK_EXPOSURE）事件。

6、呼叫 GrMapWindow() 函數顯示視窗，並產生 GR_EVENT_MASK_EXPOSURE 事件：

GrMapWindow(wid);

7、呼叫 GrMainLoop() 函數進入 Nano-X 的分派迴圈：

GrMainLoop(event_handler);

傳遞給 GrMainLoop() 函數的參數為函數指標，指向處理事件的函數（event handler）。在分派迴圈裡，若產生我們所指定的事件時就會呼叫事件處理函數，因此我們必須在事件處理函數做事件處理。

事件（Event）處理

在分派迴圈裡，產生我們所指定的事件時，就會呼叫事件處理函數。以下是 hello.c 的事件處理函數：

void event_handler(GR_EVENT *event)
{
   switch(event->type)
   {
      case GR_EVENT_TYPE_EXPOSURE:
              GrText(wid, gc, 50, 50, "Hello World", -1, GR_TFASCII);
              break;
      case GR_EVENT_TYPE_CLOSE_REQ:
              GrClose();
      default: break;
   }
}

分派迴圈會傳遞一個事件訊息的指標給事件處理函數，即程式中的event變數。我們可透過此變數來判斷所產生的事件，並做出相對應的處理：

• GR_EVENT_TYPE_EXPOSURE：視窗出現後產生此事件，我們在此事件產生後呼叫 GrText() 函數在畫面上顯示文字。
• GR_EVENT_TYPE_CLOSE_REQ：當視窗關閉的請求發生時，則產生此事件。我們在此事件產生後呼叫 GrClose() 函數關閉與nano-X server的連線。

Also See

2004.08.11: Nano-X 程式設計, #1：介紹與安裝

]]> https://www.jollen.org/blog/2004/04/nano-x_programming_2.html https://www.jollen.org/blog/2004/04/nano-x_programming_2.html GNU Toolchains & Linux Systems Programming Mon, 26 Apr 2004 20:10:32 +0800 www.jollen.org



以觀念寫成的步驟

1. 準備 host computer

一開始我們必須建立一個工作平臺 (即實驗電腦 - host computer)，也就是在 IBM PC 上安裝 Linux distribution。建議使用的 Linux distribution 為 Red Hat Linux 6.2 以上的版本，因為我們並不需要使用到 kernel 2.4 的版本，因此選擇安裝 Red Hat Linux 6.2 做為實驗環境。

您應具備的基本知識為：

• 編譯 Linux kernel
• Linux 管理技術

2. 選擇 target device

target device (目的裝置) 的選擇較常見的有 floppy disk、flash memory。現在有很多 floppy disk + Linux (floppy disk) 的 project，要製作能安裝在 floppy disk 上的最小化 Linux 並不難，一般的 Linux 開機磁片都可以稱為最小化的 Linux (利用 mkbootdisk 指令製作開機片)。

不過我們的目的是要建立給 Embedded Systems 用的 Embedded Linux，因此至少要能符合 3 項基本需求：

• 完整 system libraries：為了能執行各種應用程式。
• 標準 filesystem hierarchy：為了能提高程式在不同 Linux 系統的相容性。
• 符合 Red Hat Linux 架構：為了能順利將發展的程式由 host computer 移植到 target device。

在這裡我們選擇以 32M disk-on-Module 的 flash memory 做為 target device。

3. 在 target device 上建立 filesystem hierarchy

根據 Red Hat Linux 的階層檔案架構與 FHS 標準來建立 target device 的 filesystem hierarchy。我們可以在 host computer 上的空目錄建立後再拷貝到 target device，或是直接將 target device mount 到 host computer，直接寫入 target device。另外在 host computer 規劃一個新的分割區也是很好的做法。

若想要使用 RAM disk image，則必須在 host computer 上建立整個系統。

4. 建立 device file

使用 mknod 來建立 device file，device file 應根據 Linux Allocated Devices 文件 (Documentation/devices.txt 或 http://www.lanana.org/docs/device-list/) 來建立。通常我們只要建立會用到的 device file 即可。

在這裡為了方便起見，我們直接拿 PeeWeeLinux 的 device files 套件來使用即可，因此 /dev 裡的 device file 如下：

crw------- 1 root root 5, 1 Jan 7 2000 console lrwxrwxrwx 1 root root 3 May 5 13:07 fb -> fb0 crw-r--r-- 1 root root 29, 0 Aug 15 2000 fb0 crw-r--r-- 1 root root 29, 32 Aug 15 2000 fb1 crw-r--r-- 1 root root 29, 64 Aug 15 2000 fb2 crw-r--r-- 1 root root 29, 96 Aug 15 2000 fb3 crw-r--r-- 1 root root 29, 128 Aug 15 2000 fb4 crw-r--r-- 1 root root 29, 160 Aug 15 2000 fb5 crw-r--r-- 1 root root 29, 192 Aug 15 2000 fb6 crw-r--r-- 1 root root 29, 224 Aug 15 2000 fb7 brw------- 1 root root 2, 0 Jan 7 2000 fd0 brw------- 1 root root 2, 1 Jan 7 2000 fd1 brw-r--r-- 1 root root 100, 0 Mar 5 2001 fla brw-r--r-- 1 root root 100, 1 Mar 5 2001 fla1 brw-r--r-- 1 root root 100, 2 Mar 5 2001 fla2 brw-r--r-- 1 root root 100, 3 Mar 5 2001 fla3 brw-r--r-- 1 root root 100, 4 Mar 5 2001 fla4 crw-r--r-- 1 root root 1, 7 Jan 7 2000 full brw-rw---- 1 root root 3, 0 Jan 7 2000 hda brw-rw---- 1 root root 3, 1 Jan 7 2000 hda1 brw-rw---- 1 root root 3, 10 Jan 7 2000 hda10 brw-rw---- 1 root root 3, 11 Jan 7 2000 hda11 brw-rw---- 1 root root 3, 12 Jan 7 2000 hda12 brw-rw---- 1 root root 3, 13 Jan 7 2000 hda13 brw-rw---- 1 root root 3, 14 Jan 7 2000 hda14 brw-rw---- 1 root root 3, 15 Jan 7 2000 hda15 brw-rw---- 1 root root 3, 16 Jan 7 2000 hda16 brw-rw---- 1 root root 3, 2 Jan 7 2000 hda2 brw-rw---- 1 root root 3, 3 Jan 7 2000 hda3 brw-rw---- 1 root root 3, 4 Jan 7 2000 hda4 brw-rw---- 1 root root 3, 5 Jan 7 2000 hda5 brw-rw---- 1 root root 3, 6 Jan 7 2000 hda6 brw-rw---- 1 root root 3, 7 Jan 7 2000 hda7 brw-rw---- 1 root root 3, 8 Jan 7 2000 hda8 brw-rw---- 1 root root 3, 9 Jan 7 2000 hda9 brw-rw---- 1 root root 3, 64 Jan 7 2000 hdb brw-rw---- 1 root root 3, 65 Jan 7 2000 hdb1 brw-rw---- 1 root root 3, 74 Jan 7 2000 hdb10 brw-rw---- 1 root root 3, 75 Jan 7 2000 hdb11 brw-rw---- 1 root root 3, 76 Jan 7 2000 hdb12 brw-rw---- 1 root root 3, 77 Jan 7 2000 hdb13 brw-rw---- 1 root root 3, 78 Jan 7 2000 hdb14 brw-rw---- 1 root root 3, 79 Jan 7 2000 hdb15 brw-rw---- 1 root root 3, 80 Jan 7 2000 hdb16 brw-rw---- 1 root root 3, 66 Jan 7 2000 hdb2 brw-rw---- 1 root root 3, 67 Jan 7 2000 hdb3 brw-rw---- 1 root root 3, 68 Jan 7 2000 hdb4 brw-rw---- 1 root root 3, 69 Jan 7 2000 hdb5 brw-rw---- 1 root root 3, 70 Jan 7 2000 hdb6 brw-rw---- 1 root root 3, 71 Jan 7 2000 hdb7 brw-rw---- 1 root root 3, 72 Jan 7 2000 hdb8 brw-rw---- 1 root root 3, 73 Jan 7 2000 hdb9 brw------- 1 root root 22, 0 Jan 7 2000 hdc brw-rw---- 1 root root 22, 1 Jan 7 2000 hdc1 brw-rw---- 1 root root 22, 10 Jan 7 2000 hdc10 brw-rw---- 1 root root 22, 11 Jan 7 2000 hdc11 brw-rw---- 1 root root 22, 12 Jan 7 2000 hdc12 brw-rw---- 1 root root 22, 13 Jan 7 2000 hdc13 brw-rw---- 1 root root 22, 14 Jan 7 2000 hdc14 brw-rw---- 1 root root 22, 15 Jan 7 2000 hdc15 brw-rw---- 1 root root 22, 16 Jan 7 2000 hdc16 brw-rw---- 1 root root 22, 2 Jan 7 2000 hdc2 brw-rw---- 1 root root 22, 3 Jan 7 2000 hdc3 brw-rw---- 1 root root 22, 4 Jan 7 2000 hdc4 brw-rw---- 1 root root 22, 5 Jan 7 2000 hdc5 brw-rw---- 1 root root 22, 6 Jan 7 2000 hdc6 brw-rw---- 1 root root 22, 7 Jan 7 2000 hdc7 brw-rw---- 1 root root 22, 8 Jan 7 2000 hdc8 brw-rw---- 1 root root 22, 9 Jan 7 2000 hdc9 brw-rw---- 1 root root 22, 64 Jan 7 2000 hdd brw-rw---- 1 root root 22, 65 Jan 7 2000 hdd1 brw-rw---- 1 root root 22, 74 Jan 7 2000 hdd10 brw-rw---- 1 root root 22, 75 Jan 7 2000 hdd11 brw-rw---- 1 root root 22, 76 Jan 7 2000 hdd12 brw-rw---- 1 root root 22, 77 Jan 7 2000 hdd13 brw-rw---- 1 root root 22, 78 Jan 7 2000 hdd14 brw-rw---- 1 root root 22, 79 Jan 7 2000 hdd15 brw-rw---- 1 root root 22, 80 Jan 7 2000 hdd16 brw-rw---- 1 root root 22, 66 Jan 7 2000 hdd2 brw-rw---- 1 root root 22, 67 Jan 7 2000 hdd3 brw-rw---- 1 root root 22, 68 Jan 7 2000 hdd4 brw-rw---- 1 root root 22, 69 Jan 7 2000 hdd5 brw-rw---- 1 root root 22, 70 Jan 7 2000 hdd6 brw-rw---- 1 root root 22, 71 Jan 7 2000 hdd7 brw-rw---- 1 root root 22, 72 Jan 7 2000 hdd8 brw-rw---- 1 root root 22, 73 Jan 7 2000 hdd9 prw------- 1 root root 0 Jan 7 2000 initctl crw-r----- 1 root root 1, 2 Jan 7 2000 kmem brw-rw---- 1 root root 7, 0 Jan 7 2000 loop0 brw-rw---- 1 root root 7, 1 Jan 7 2000 loop1 brw-rw---- 1 root root 7, 2 Jan 7 2000 loop2 brw-rw---- 1 root root 7, 3 Jan 7 2000 loop3 brw-rw---- 1 root root 7, 4 Jan 7 2000 loop4 brw-rw---- 1 root root 7, 5 Jan 7 2000 loop5 brw-rw---- 1 root root 7, 6 Jan 7 2000 loop6 brw-rw---- 1 root root 7, 7 Jan 7 2000 loop7 crw-rw-rw- 1 root root 1, 1 Jan 7 2000 mem lrwxrwxrwx 1 root root 5 May 5 13:07 mouse -> psaux crw-rw-rw- 1 root root 1, 3 Jan 7 2000 null crw-r----- 1 root root 1, 4 Jan 7 2000 port crw-rw---- 1 root root 10, 1 May 6 1998 psaux brw-r----- 1 root root 1, 1 Jan 7 2000 ram brw-rw---- 1 root root 1, 0 Jan 7 2000 ram0 brw-rw---- 1 root root 1, 1 Jan 7 2000 ram1 brw-rw---- 1 root root 1, 2 Jan 7 2000 ram2 brw-rw---- 1 root root 1, 3 Jan 7 2000 ram3 brw-rw---- 1 root root 1, 4 Jan 7 2000 ram4 brw-rw---- 1 root root 1, 5 Jan 7 2000 ram5 brw-rw---- 1 root root 1, 6 Jan 7 2000 ram6 brw-rw---- 1 root root 1, 7 Jan 7 2000 ram7 brw-rw---- 1 root root 1, 8 Jan 7 2000 ram8 brw-rw---- 1 root root 1, 9 Jan 7 2000 ram9 lrwxrwxrwx 1 root root 4 May 5 13:07 ramdisk -> ram0 crw-r--r-- 1 root root 1, 8 Jan 7 2000 random crw-rw-r-- 1 root root 10, 135 Jan 7 2000 rtc brw-rw---- 1 root root 8, 0 May 6 1998 sda brw-rw---- 1 root root 8, 1 May 6 1998 sda1 brw-rw---- 1 root root 8, 2 May 6 1998 sda2 brw-rw---- 1 root root 8, 3 May 6 1998 sda3 brw-rw---- 1 root root 8, 4 May 6 1998 sda4 brw-rw---- 1 root root 8, 16 May 6 1998 sdb brw-rw---- 1 root root 8, 17 May 6 1998 sdb1 brw-rw---- 1 root root 8, 18 May 6 1998 sdb2 brw-rw---- 1 root root 8, 19 May 6 1998 sdb3 brw-rw---- 1 root root 8, 20 May 6 1998 sdb4 brw-rw---- 1 root root 8, 32 May 6 1998 sdc brw-rw---- 1 root root 8, 33 May 6 1998 sdc1 brw-rw---- 1 root root 8, 34 May 6 1998 sdc2 brw-rw---- 1 root root 8, 35 May 6 1998 sdc3 brw-rw---- 1 root root 8, 36 May 6 1998 sdc4 brw-rw---- 1 root root 8, 48 May 6 1998 sdd brw-rw---- 1 root root 8, 49 May 6 1998 sdd1 brw-rw---- 1 root root 8, 50 May 6 1998 sdd2 brw-rw---- 1 root root 8, 51 May 6 1998 sdd3 brw-rw---- 1 root root 8, 52 May 6 1998 sdd4 crw------- 1 root root 4, 0 Jan 7 2000 systty crw-rw-rw- 1 root root 5, 0 Jan 7 2000 tty crw------- 1 root root 4, 0 Jan 7 2000 tty0 crw--w---- 1 root root 4, 1 Jan 7 2000 tty1 crw------- 1 root root 4, 2 Jan 7 2000 tty2 crw------- 1 root root 4, 3 Jan 7 2000 tty3 crw------- 1 root root 4, 4 Jan 7 2000 tty4 crw------- 1 root root 4, 5 Jan 7 2000 tty5 crw------- 1 root root 4, 6 Jan 7 2000 tty6 crw------- 1 root root 4, 7 Jan 7 2000 tty7 crw------- 1 root root 4, 8 Jan 7 2000 tty8 crw------- 1 root root 4, 9 Jan 7 2000 tty9 crw------- 1 root root 4, 64 Jan 7 2000 ttyS0 crw------- 1 root root 4, 65 Jan 7 2000 ttyS1 crw------- 1 root root 4, 66 Jan 7 2000 ttyS2 crw------- 1 root root 4, 67 Jan 7 2000 ttyS3 crw-r--r-- 1 root root 1, 9 Jan 7 2000 urandom crw-rw-rw- 1 root root 1, 5 Jan 7 2000 zero


真正的 Embedded Linux 應用會以 mknod 或是 mkext2fs 指令來建立 device files，並且 /dev 目錄下也只會有真正用到的 device files，不會有這麼多的 device file。

5. 安裝 glibc 至 target device

glibc 是標準 C 程式庫，我們可以直接由 host computer 將 glibc 的檔案拷貝到 target device。如果您想使用與 host computer 不同版本的 glibc，則要注意版本的向下相容性問題；不過建議 target device 與 host computer 的環境最好要一樣，這樣比較容易測試與除錯。

因為 Linux 是支援 shared libraries 的 OS，所以 target device 與 host computer 的 glibc 版本不同也不需要重新編譯所有的程式，除非 target device 不是在 x86 上執行，這時才需要做重新編譯 (corss-compiling) 的動作。

glibc 也可以考慮改用專用給 Embedded Systems 用的 uClibc。

6. 建立 base Linux system

base Linux system 的建立包括安裝其它 system libraries、utilities、compiler、shell ... 等等，至於到底應該要有什麼基本系統，應參考 LSB 標準。另外 LFS 文件也只做為建立 base Linux system 的參考，但建議應以 LSB 標準為主。

另外 Lineo 公司也發展許多專門給 Embedded System 用的高品質軟體，因此請使用底下 2 個專案套件：

(http://opensource.lineo.com/projects.html)

• BusyBox (大量使用中的熱門專案)
• TinyLogin (大量使用中的熱門專案)

uClibc 與有名的 uClinux 也都是 Lineo 公司的貢獻。

7. 設定 init

init 的設定就比較容易了，我們只要根據 runlevel 來設定 /etc/inittab 即可。另外，如果要跟 Red Hat Linux 的 /etc/rc.d 架構相容，可以自行修改 BusyBox 裡的 init.c 程式 (#define INIT_SCRIPT)。

請參考「Embedded Linux 的系統管理,#3: initial scripts」一文。

8. 編譯 Linux kernel

根據 target device 所在的硬體環境編譯 Linux kernel。編譯好後會得到 Linux kernel image (zImage/bzImage)。

我們的課程會為同學事先準備好已編譯完成的 Linux kernel。

9. 設定 boot loader

Linux 下的 boot loader 從老當益壯的 LILO、syslinux，到 grub 都可以使用。使用 DOM 的話，假如 boot loader 發生「not found BIOS drive」的話，只要手動做 BIOS 位址設定即可。以 LILO 為例，則是：

disk = /dev/hdc bios = 0x80 boot = /dev/hdc

10. (參考) 使用 RAM disk image

前面 (~9.) 我們將 Linux 系統放在 physical 儲存裝置，如果您想讓檔案系統放在 RAM 裡 (例如在 RAM 很多的 PC 上)，可以使用 RAM disk 技術，將檔案系統與 Linux kernel image 做成 compressed RAM disk image。

Embedded Linux 解決方案

前面我們介紹純手工打造的最小化 Linux，不過就非特殊用途的場合來講，現在有很多 Embedded Linux distribution 的現成解決方案可以給怕麻煩的人使用，我們可以不必親自從零開始做起。例如 PeeWeeLinux、Embedded Debian 或其它商業性質的產品。

結語

在這裡我們針對建立最小化 Linux 的觀念做了介紹，Embedded Linux 系統的基礎為最小化的 Linux，本文章說明製作最小化 Linux 的方法、步驟與觀念。

]]> https://www.jollen.org/blog/2004/03/_linux.html https://www.jollen.org/blog/2004/03/_linux.html Embedded Linux: Platforms and Applications Fri, 05 Mar 2004 11:04:50 +0800 uClinux 介紹

uClinux 唸做「you-see-linux」，是由字置詞「u」（micro之意）與「c」（control之意）所組成的複合字。由 uClinux 的名稱可以知道，這是將Linux 移植到控制用微控制處理器上的 Linux kernel。

目前 uClinux 已經將 Linux kernel 的移植（porting）到許多不同的處理器架構上，uClinux 目前移植的 kernel 最新版本為： kernel 2.0.39、kernel 2.4.32 與 kernel 2.6.17。

uClinux 所支援的處理器有：M68k、ColdFire、ARM、Sparc、NEC v850、H8/300、OPENcores OR1000、Altera NIOS and Xilinx Microblaze。

uClinux 本身是 Linux kernel 的移植，許多情況下我們都可以直接使用廠商提供事先編譯完成的 uClinux。若想要自行編譯給 ARM 使用的 Linux kernel，建議使用uClinux-dist。

uClinux-dist 介紹

uClinux 有許多不同處理器平臺的移植，uClinux-dist 則是將不同處理器的 uClinux 整合至一個套件裡。此外，uClinux-dist 也整合了許多的軟體與系統工具，並且提供設定 root filesystem 的介面。

因此，使用 uClinux-dist 可以很方便的設定 Linux kernel 與 root filesystem，並且透過 uClinux-dist 的 Makefile 環境，我們就可以很方便的做跨平臺編譯。針對不同平臺所需要的其它處理工作（如 FLAT 格式轉換、.text/.data 節區的切割等等），uClinux-dist 也會自動幫我們完成。

可以小結使用 uClinux-dist 的主要好處有：

˙ 簡化編譯過程
˙ 不需下達雜複的 arm-elf-gcc 參數
˙ 不需下達雜複的 arm-elf-ld 參數
˙ 自動進行 kernel 的 .text/.section 節區處理
˙ 將 ELF 格式轉 FLAT 格式
˙ 自動進行 VMA 與 LMA 的位址重新對應
˙ 處理不同平臺的新增節區設定

除此之外，uClinux-dist 也提供 glibc/uClibc/uC-libc 的選擇，因此建議大家下載 uClinux-dist 使用。uClinux-dist 的官方下載網址：http://www.uclinux.org/pub/uClinux/dist/

由於編譯完成的 uClinux kernel 還需要針對硬體平臺做許多處理才能下載到實驗板使用，例如：針對不同的程式起啟位址重新調整所有節區的VMA/LMA 位址，因此若透過 uClinux-dist 的整合環境，便可以簡化我們的工作。

注記

• 2006.12.27: 更新（Editor: Jollen）
]]> https://www.jollen.org/blog/2004/02/uclinux_uclinux-dist.html https://www.jollen.org/blog/2004/02/uclinux_uclinux-dist.html Embedded Linux: Platforms and Applications Thu, 26 Feb 2004 13:40:42 +0800 uClinux-dist 基本操作

將uClinux-dist-20030909.tar.gz解壓後，執行：

# make menuconfig

進入文字選單設定介面（圖1）。



圖1 uClinux-dist的設定主選單

進入「Target Platform Selection」選單，開始設定target端平臺的參數（圖2）。



圖2 選擇 Vendor/Product

在 uClinux-dist 裡已經預先建立許多平臺的參數資料，因此我們可以在「Vendor/Product」選單裡選取我們的硬體平臺，並使用 uClinux-dist 的預設參數。

在這裡我們選擇「GDB/ARMulator」來配合後面的章節進行實作（圖3）。



圖3 在Vendor/Product選項中找到 GDB/ARMulator平臺

接著在「kernel Version」選單中選則 Linux kernel 版本，在這裡我們選擇「linux-2.0.x」（圖4）。



圖4 使用linux-2.0.x

再來是有關filesystem的設定。在「Libc Version」裡，選擇「uC-libc」做為標準C程式庫（圖5）。



圖5 使用uC-libc

回到「Target Platform Selection」主選單，選擇「Customize kernel Settings (NEW)」後儲存設定離開（圖6）。



圖6 選取「Customize Kernel Settings (NEW)」進入kernel設定介面

在圖6的畫面中連續選擇「Exit」後會出現圖7的畫面，在此畫面選擇「Yes」儲存設定後離開。



圖7 儲存設定後離開

uClinux kernel設定選單

離開uClinux-dist主選單後，會進入Linux kernel的設定選單（圖8）。



圖8 Linux kernel設定選單

在 Linux kernel的設定選單裡進行相關設定，其中關於記憶體使用配置可查詢各平臺的使用手冊。設定完成後儲存離開。由於我們選擇的平臺為 GDB/ARMulator，因此直接使用預設值即可。選擇「Exit」儲存設定後離開（圖9）。



圖9 儲存 kernel 設定後離開

Filesystem 設定選單

若在 uClinux-dist 主選單選擇「Customize Vendor/User settings (NEW)」（圖6）則可以自行設定 filesystem。圖7是 uClinux-dist 的 filesystem 設定介面，在這裡我們可以自行設定 filesystem 的套件。



圖10 Filesystem 設定選單

設定完成後選擇「Exit」，然後再選擇「Yes」儲存設定後離開。

注記

• 2006.12.27: 本文是以 20030909 的 uClinux-dist 為例，目前最新版本是 20060803。（Edit by Jollen）
]]> https://www.jollen.org/blog/2004/02/uclinux_uclinux-dist_2.html https://www.jollen.org/blog/2004/02/uclinux_uclinux-dist_2.html Embedded Linux: Platforms and Applications Thu, 26 Feb 2004 13:40:32 +0800 編譯 uClinux-dist

完成 kernel 與 filesystem 設定後，在命令模式執行編譯命令：

# make dep
# make

進行 kernel 與應用程式的跨平臺編譯。在編譯之前，請檢查跨平臺編譯工具組（如GNU armtools）是否已安裝，同時在環境變數 PATH 的搜尋路徑裡也要能找到相關的程式。

uClinux-dist 會幫我們製作 root filesystem 的映像檔（image file），最後編譯完成的 kernel 與 root filesystem 映像檔會存放於 image/ 目錄下。編譯成功後會得到 4 個主要的檔案如下：

˙ images/linux.text：kernel的.text節區。
˙ images/linux.data：kernel的.data節區。
˙ images/romfs.img：filesystem的映像檔。
˙ images/image.bin：以上 3 個檔案合併後的映像檔。

在這裡我將 uClinux-dist 設定成「GDB/ARMulator」，這樣我們之後就可以用 GDB/ARMulator 來玩這個 root filesystem 了。

常見問題

在許多無法成功編譯 uClinux-dist 的案例中，最常見到的問題有2個。

第一種情況為 GNU armtools 安裝不完整，導致在編譯的過程中出現錯誤，例如在 uClinux-dist 中選用 uClibc，但並未安裝 uClibc 套件，或是系統設定的問題，導致編譯器無法找到正確的程式庫位置。因此若在編譯 uClinux-dist 的過程出現錯誤，請先檢查 GNU armtools 的安裝是否完整，同時也記得安裝所選用的 C 程式庫。

第二種情況為套件的設定與 C 函式庫有衝突，例如有些套件不能使用 uClibc，必須改用 uC-libc 才能成功編譯。

]]> https://www.jollen.org/blog/2004/02/uclinux_uclinux-dist_3.html https://www.jollen.org/blog/2004/02/uclinux_uclinux-dist_3.html Embedded Linux: Platforms and Applications Thu, 26 Feb 2004 13:40:31 +0800 由 uClinux 網站下載 GNU armtools：

http://www.uclinux.org/pub/uClinux/m68k-elf-tools/

請下載此檔案：

http://www.uclinux.org/pub/uClinux/m68k-elf-tools/arm-elf-tools-20030314.sh

下載完成後，直接執行 arm-elf-tools-20030314.sh 即可安裝：

# sh arm-elf-tools-20030314.sh

uClinux 所提供的 GNU armtools 會安裝於 /usr/local 目錄下。

FLAT 格式的轉換工具

uClinux 所提供的 GNU armtools 也有一個用來處理 FLAT 格式轉換的工具，因此我們會有以下 2 個執行檔：

˙ /usr/local/bin/arm-elf-ld：呼叫arm-elf-ld.real並協助我們將檔案轉換成FLAT格式。
˙ /usr/local/bin/arm-elf-ld.real：真正的linker。

使用 uClinux 的 toolchains 時，只要在執行 arm-elf-ld 時加上 '-elf2flt' 參數即可將檔案轉換成 FLAT 格式；另外，設定 FLTFLAGS 環境變數，即可傳遞參數給 elf2flt 指令。例如：'export FLTFLAGS=-z' 表示要製作成 ZFLAT 的格式。

]]> https://www.jollen.org/blog/2004/02/uclinux_uclinux-dist_4.html https://www.jollen.org/blog/2004/02/uclinux_uclinux-dist_4.html Embedded Linux: Platforms and Applications Thu, 26 Feb 2004 13:40:17 +0800 一開始執行 GDB/ARMulator 時，指定 kernel 做為執行檔：

# /usr/local/bin/arm-elf-gdb linux.2.0.x
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf"...
(no debugging symbols found)...

注意！GDB/ARMulator 是 GDB 加上 ARMulator patch 後的特殊版本，必須自行由 GDB 原始碼製作。

進入 gdb 命令模式後，在 gdb 命令模式下輸入 target sim 命令：

(gdb) target sim
Loaded ROM boot.rom
Loaded ROM boot.rom
Loaded ROM boot.rom
Loaded ROM boot.rom
Connected to the simulator.

指定 taget 端為 ARM simulator。此時 GDB 會載入 boot.rom 做為 root filesystem，因此請將 root filesystem的檔案名稱修改為 boot.rom（或建立link）。接著再輸入 load 命令載入kernel：

(gdb) load
Loading section .text, size 0x77b84 vma 0x2000000
Loading section .rodata, size 0x8ddb vma 0x2077b84
Loading section .data, size 0x8fc8 vma 0x2080a60
Start address 0x2000000
Transfer rate: 4507960 bits/sec.

由 GDB 的訊息可以看出，uClinux for GDB/ARMulator 的 .text 節區起始位址為 0x20000000，此位址會因為硬體平臺的不同而不同。uCliinux-dist 已經幫我們設定好許多平臺的起始位址參數，因此使用 uClinux-dist 時就不必自己手動重設節區位址。

輸入run命令開機：

(gdb) run

執行結果：

Starting program: /home/Embedded/GDB/linux.2.0.x
Found an Atmel AT91F40xxx arm7 processor
Atmel AT91 series microcontroller support (c) 2000,2001 Lineo Inc.
kernel binary is in RAM -- reserving 643k for the kernel
Calibrating delay loop.. ok - 13.00 BogoMIPS
Memory: 1372k/2048k available (224k kernel code, 0k reserved, 196k data)
Swansea University Computer Society NET3.035 for Linux 2.0
NET3: Unix domain sockets 0.13 for Linux NET3.035.
Swansea University Computer Society TCP/IP for NET3.034
IP Protocols: ICMP, UDP, TCP
Linux version 2.0.39.uc2 (davidm@moby) (gcc version 2.95.3 20010315 (release)(ColdFire patches - 20010318 from http://fiddes.net/coldfire/)(-msep-data patches)) 41 Fri Jun 14 10:54:27 EST 2002
Atmel USART driver version 0.99
ttyS0 at 0xfffd0000 (irq = 2) is a builtin Atmel APB USART
ttyS1 at 0xfffcc000 (irq = 3) is a builtin Atmel APB USART
Ramdisk driver initialized : 16 ramdisks of 4096K size
Blkmem copyright 1998,1999 D. Jeff Dionne
Blkmem copyright 1998 Kenneth Albanowski
Blkmem 1 disk images:
0: 4000000-B4BB07FF (RO)
PPP: version 2.3.8 (demand dialling)
TCP compression code copyright 1989 Regents of the University of California
PPP line discipline registered.
PPP MPPE compression registered
SLIP: version 0.8.4-NET3.019-NEWTTY (dynamic channels, max=256).
CSLIP: code copyright 1989 Regents of the University of California.
VFS: Mounted root (romfs filesystem).
Shell invoked to run file: /etc/rc
Command: hostname GDB-ARMulator
Command: /bin/expand /etc/ramfs.img /dev/ram0
Command: mount -t proc proc /proc
Command: mount -t ext2 /dev/ram0 /var
Command: mkdir /var/tmp
Command: mkdir /var/log
Command: mkdir /var/run
Command: mkdir /var/lock
Command: cat /etc/motd
Welcome to
____ _ _
/ __| ||_|
_ _| | | | _ ____ _ _ _ _
| | | | | | || | _ \| | | |\ \/ /
| |_| | |__| || | | | | |_| |/ \
| ___\____|_||_|_| |_|\____|\_/\_/
| |
|_|

GDB/ARMulator support by <davidm@snapgear.com>
For further information check:
http://www.uclinux.org/

Execution Finished, Exiting

Sash command shell (version 1.1.1)
/>

]]> https://www.jollen.org/blog/2004/02/uclinux-dist_gdbarmulator.html https://www.jollen.org/blog/2004/02/uclinux-dist_gdbarmulator.html Embedded Linux: Platforms and Applications Thu, 26 Feb 2004 13:40:03 +0800 www.jollen.org



Video Streaming 系統概觀

一個完整的 Video Streaming 系統應該包含四個部份：

• Content (例如影像、聲音、coded 資料)

• Server

• Client

• Data network (例如 Internet，或任何連結 server-client 的媒介)

那麼我們在這一系列 Video Streaming 主題介紹的有那些呢？從一開始的名詞介紹、影像擷取、RTP 通訊協定，我們將重心放在 contente 與 data network 上。當然我們系列主題名為「Linux 的應用」，最關鍵的地方則是在如何在 Linux 環境下設計影像擷取程式。

對於 data network 的部份因為與 Linux 較無關，但也是 Video Streaming 的重點主題之一，所以也介紹了 jrtplib 這套程式庫給大家，在底下的部份也會補充 Nsync 這套 toolkit。

而 server 端似乎是我們著墨不深的地方，但也沒關係，在這最後一篇的文章裡，我們針對理論方面做補充的介紹，我們將以 Video Conferencing 實作時，實務上會面臨的主題來做解，包括：多媒體資料的儲存、OS 的磁碟排程 (SCAN-EDF)，以做為您搜尋參考資料的起頭。

在 client 方面，我們在最後的完整版範例程式時，示範了如何利用 SDL 將擷取下來的影像資料秀在螢幕上。這裡也會配合了上一篇所介紹的 mmap 擷取方式，以將影像資料填入 SDL 的 display 結構方式秀圖。

Video Streaming 的開始

我們一開始就介紹了 Video Streaming 是一種經由網路來撥放影音檔案的技術，Video "Streaming" 的基本概念爲「一邊下載一邊撥放」，我們稱之爲「Play as received」。

經由 Internet 如果要收看遠端伺服器的電影檔案，最原始的做爲是「下載後再撥放」，也就是經由 FTP 或 HTTP 將整個檔案下載至本地端後再利用撥放程式來撥放，我們稱之爲「Play after download」。

舉個最簡單的情況，你可能在下載 MP3 之前想要試聽一下音樂的內容，而下載音樂片段的方式又顯得不夠友善，這時如果利用 Video Streaming 的技術來讓網友視聽，不但方便，而且不必浪費時間來下載不喜歡的音樂的。

除此之外，大家最熟悉的莫過於在線上即時播放影片的 real player了。

Real Video 產品介紹

Real Video 是 Real Networks 公司的產品，Real Video 主要支援了 video-on-demand*1 的功能。Real Video 可以讓我們經由網站來播放串流影像 (streaming video)。

由於我們的最終目的是實作出一個可以做 video streaming 的軟體，所以在這裡我們將以 Real Video 做為標竿，並以 Linux 為基礎來設計 video streaming 的軟體。

其它經典的 streaming 範例程式

網路上有幾套很值得玩味研究的相關開放原始碼軟體，我們也曾經提過。VIC 和 VideoLAN 則是其中絕對優秀的教學範例。

VIC

VIC 也是屬於 Open Source 的軟體。VIC 全名為video conferencing，故名其義，VIC 是一種視訊會議的軟體。VIC 是由加州柏克來大學的 Network Research Group 所發展。

VIC 是相當棒非常適合用來研究 Video Streaming 的 Open Source 軟體，主要是因為 VIC 幾乎包含了 Video Streaming 相關的技術。

VIC 值得我們研究的原因是因為 VIC 支援了底下所列的功能：

• IPv6

• 使用 video4linux 的影像擷取功能

• H261、H263 與 H263+ codec

• Software JPEG 與 BVC 編碼

• Raw YUV packetiser/codec

• RTIP/RTP 通訊協定

• the IP Multicast Backbone (MBone)

• 支援 video4linux 的 mmap

這些特色幾乎已經包括 Video Streaming 所應具備的技術了，基於這些特點，VIC 的原始程式碼相當吸引人，因此有意研究 Video Streaming 的 programmer 應該好好閱讀一下 VIC 的原始程式碼。

VideoLAN

VideoLAN 是一個可以做 MPEG 與 DVD 擴播 (broadcast) 播放的軟體，VideoLAN 分成二個部份，一個是 VLAN server，另一個則是 vlc 用戶端播放程式。

VLAN server 將 DVD 與 MPEG 影像利用 broadcast 方式擴播到區域網路上，使用者端再利用 vlc 接收封包並播放。這樣做的好處是可以減少重覆的 I/O 動作，VLAN server 將影像擴播出去後，區域網路上的用戶端再利用 vlc 接收封包並播放。

VideoLAN 支援 X11、SDL、Linux framebuffer、GGI、BeOS API、MacOS X API 播放方式，並且支援 DVD 與 AC3 (杜比音效)。

影像編碼技術介紹 (coded)

目前學術界已經發展出許多處理影像訊號壓縮及編碼的技術 (codecs)，談到這些技術，應用最廣泛的編碼標準底下四種：

• H.261

• H.263

• JPEG, MJPEG

• MPEG

本文第一篇文章就是在對這四種編碼技術做簡單的介紹。

data network 的技術主題

Video 在做 Streaming 時，有三種方式可以應用：broadcasting、unicasting、multicasting。

broadcasting 的方式比較單純，他是在 LAN 上直接將一個個的影像封包丟到網路上 (server 端)，再由 client 的應用程式自網路上取回封包播放。但網路硬體層上，仍有許多需要考慮的問題，例如在 Shared Non-Switched Enthernet 上時，就會發生一些小問題。

unicasting 與 multicasting 都是屬於 IP 的傳輸方式。unicasting 採取 1 對 1 的方向傳影像給遠端，稱為 Video-on-Demand (VoD)，multicasting 則是 1 對多的傳輸方式，稱為 Near-Video-on-Demand (NVoD)。未來 IPv6 將支援 IP Multicasting，因此 Video Streaming 的應用將更為廣泛。

在通訊協定方面，我們也介紹了 RTP。

RTP 全名為 Real-Time Protocol，RTP 是在 UDP 封包之前多加 10 bytes 的檔頭，裡面記載有時間、序號、壓縮型態等資訊。RTP 是目前大多數 Video Streaming 軟體所使用的通訊協定。

RTP 可用來針對各種不同的多媒體格式做 Streaming 的工作，因為我們將影像分解成數個 RTP 封包再傳送出去，因此會遇到許多網路技術常會遇到的問題。例如，因為封包送達的時間不一，造成播放時會畫面不流暢的現像，因此，在播發時就必須使用一個緩 衝區 (playout buffer) 來暫時存放並處理網路上接受到的封包。

由網路上接收的影像封包因為彼此之間到達的時間間隔不同 (Synchronous Data Packets)，所以必須利用緩衝區將這些封包做緩衝，讓彼此之間的時間間隔一樣 (Isochronous Data Packets)。

其它重要的通訊協定像是 SIP、或是 FEC (forward error correction) 除錯技術，都是一定要去研究的主題。

影像擷取卡

在 Linux 下設計影像擷取程式，當然一定要配備有適合的影像擷取卡。

我們曾經介紹給大家的是 Osprey 100 這張影像擷取卡。Osprey 100 是 Real Networks 公司所推薦配合他們產品的一張影像擷取卡，配合 Osprey 100 與 RealNetworks 的產品我們可以利用 broadcast 或 on-demand 做到實況轉播 (live) 的功能。

Osprey 100 在硬體功能上可以支援到每秒 30 個畫面 (fps -- frame per second)，並且支援 NTSC 與 PAL 輸入。

不過在實作上，筆者並不使用 Osprey 100。筆者使用的影像擷取卡是 ，這張卡算是比較「俗」一點的卡，但是也有好處，因為在 Linux 上很容易安裝。

以筆者這張卡為例，使用的是 Brooktree Corporation 的卡，所以只要安裝 bttv 模組即可，同時，bttv 模組在 Linux kernel 2.2.17 下也會用到 i2c-old 與 videodev 兩個模組，所以也要一併安裝。在命令列下，安裝這三個模組的命令為：

linux# insmod i2c-old
linux# insmod videodev
linux# insmod bttv

當然要確定 Linux kernel 有編譯這三個模組的支援，然後再把這三個模組加到 /etc/modules.conf (Red Hat 7.0) 裡。

不同版本的 kernel 所要安裝的模組不一定相同！還請注意，例如 i2c 相關模組就是如此。

Linux 上可用的影像擷取卡

在http://www.linhardware.com/db/searchproduct.cgi?_catid=17 網頁上可以找到在 Linux 上支援程度比較好的幾張影像擷取卡。而一般 Linux 上較受歡迎的影像擷取卡則是 Hauppauge 的幾張卡, 筆者使用的也是 Hauppauge 的卡。

在 linhardware 網站上可以找到底下六張卡:

• Hauppauge 401 WinTV-radio dbx-TV stereo

• Hauppauge WinTV PCI TV Card

• Hauppauge WinTV-GO PCI TV Card

• Hauppauge WinTV-PCI Hauppauge

• Hauppauge WinTV-Radio+NICAM

• Hauppauge WinTV/PCI TV Card

關於 Linux 對於影像擷取卡支援的中文文件 (HOWTO) 可以在 CLDP 網站上取得:

http://www.linux.org.tw/CLDP/Hardware-HOWTO-22.html

影像擷取卡支援的視訊系統

大部份影像擷取卡都會具備一組視訊輸入端子, 即 S-Video (Y/C) 端子或 Composite 端子。

在台灣的標準當然是 NTSC 系統, 一般而言, 我們是希望一張影像擷取卡可以支援越多視訊系統越好, 包括: NTSC/PAL/PALN/PLAM/SECAM。

可使用的視訊裝置有較常見的 CCD, 或是家用 V8、Hi8 皆可, 一般而言我們也是希望一張影像擷取卡可以接越多視訊裝置越好。

BT 878 晶片

跟隨在影像擷取卡之後的主題當然就是 BT878 晶片的介紹，因為支援 BT 8x8 晶片的 BTTV 軀動程式是我們設計影像擷取軟體的核力主力！

目前大部份的數位影像擷取卡大部份都是以 BT878 單顆晶片為影像擷取卡之中心。BT878 運作方式是以軟體來進行影像解壓縮工作, BT878 晶片負責將擷取之影像丟給 Linux 做影像處理, 而 BTTV 則是 Linux kernel 的 BT878 晶片軀動程式。

由於影像是利用 BT878 擷取後交由軟體來做影像處理, 因此在處理效能上自然就會比較差。如果是經由網路來傳送影像的話, 我們就會再利用影像壓縮技術 (H.261/H.263...等等) 來做影像處理。

什麼是 BTTV

BTTV 是 Linux 上的 Bt848/849/878/879 晶片的軀動程式, 主要功能是做頁框的截取 (frame grabber)。

BTTV 是 video4linux 裡重要的軀動程式, 目前分為二個版本:

• 0.8.x 的發展中版本

• 0.7.x 的穩定版本

BTTV 相關應用軟體 - xawtv

官方網站: http://bytesex.org/xawtv/index.html

安裝方式:

linux# ./configure
linux# make depend
linux# make
linux# make install

如果您有 Red Hat Linux 7.1 PowerTools 光碟片的話, 也可以直接由 PowerTools 光碟片安裝 xawtv 套件:

linux# rpm -ivh xawtv-3.34-1.i386.rpm

安裝 xawtv 需要 libjpeg 與 libjpeg-devel 套件, 如果您是使用 Red Hat Linux 7.1 的話, 應該安裝底下二個套件:

• libjpeg-6b-15.i386.rpm (Disc 1)

• libjpeg-devel-6b-15.i386.rpm (Disc 2)

xawtv 整個架構可以分成 7 個部份如下:

• xawtv: 主程式部份。

• fbtv: linux console 模式的 TV 應用程式, 使用 linux kernel 2.2.x 的 framebuffer。

• set-tv: 命令列模式的工具, 用來設定 video4linux 的參數。

• streamer: 命令列模式的工具, 用來捉取動態影像與 avi 影像。

• radio: radio 應用程式。

• webcam: 將捉取的影像以 FTP 方式上傳到 Web Server 端, 用來設計 Web 即時影像的工具。

• alevtd: videotext pages 的 Web Server。

xawtv 的 video4linux

xawtv 是相當好的 video4linux 方面的教材，我們極力推薦讀者研究 xawtv 的 video4linux 部份的原始碼。

將取回 xawtv 的原始程式碼解開後, 在 libng/ 目錄下可以看到 grab-v4l.c 的檔案, 另外還有一個 grab-v4l2.c 的檔案, 這是 video4linux2 (version 2) 的版本。

在 xawtv 的 video4linux 主題現身之前，我們很詳盡介紹了 video4linux 的基本設計方法，接下來在 xawtv 之後更是再進一步說明了 video4linux 的經典 – mmap 擷取技巧。

那麼跨越三期內容的程式碼那一個才是完整的呢？事實上都沒有，不過請讀者們放心，本期我們將列出所有我們曾經介紹過的主題所實作的程式，當然是完整的實作程式碼！

video4linux 使用的設備檔

Linux 下與 video4linux 相關的設備檔與其用途：

/dev/video	Video	Capture Interface
/dev/radio	AM/FM	Radio Devices
/dev/vtx	Teletext	Interface Chips
/dev/vbi	Raw	VBI Data (Intercast/teletext)

video4linux 除了提供 programmer 與影像擷取有關的 API 外，也支援其它像是收音機裝置。

接下來介紹 video4linux 設計方式，所使用的 Linux kernel 版本為 2.2.16。這篇文章將簡單介紹實作 video4linux 的方法，所以請準備好 Linux kernel 原始碼下的 Documentation/v4l/API.html 文件並了解 What's video4linux。

Video Streaming 的其它關鍵議題

接下來的主題將介紹 Video Streaming 其它值得研究的主題，我們會在最後才提出來的原因是因為這些主題將不會影響我們之前的程式實作，但在設計完整的 Video Streaming 系統時，則是有必要加以考慮的。

Video Conferencing 應用的重要性

Video Conferencing 在多媒體設計上之所以重要，最重要的原因是因為 Video Conferencing 渉及的技術議題包括：

• 即時性問題 (real-time systems problem)

• 互動式應用程式的 latency 與 throughput 問題

這樣的問題當然首先是發生在網路頻寬的問題上，由於網路視訊會議系統耗費大量的頻寬，而且網路視訊會議的品質也容易受網路品質與頻寬影響，因此這是值得我們研究的問題之一。

Video Conferencing 另外一個迷人的地方是在於 Video Conferencing 提供良好的 person-to-person 環境。Video Conferencing 應用軟體在多媒體程式設計上，常常也被視為「殺手級」的應用之一，可見 Video Conferencing 應用的重要性。

Video Conferencing 的應用領域

Video Conferencing 目前的應用領域則是有：遠距教學 (distance learning systems)、遠端診視系統 (remote consultation systems)、遊戲…等等。

就如同我們先前所講的，解決網路、傳輸問題變成是下一代通訊應用的的關鍵。在軟體的支援上也是如此，當然這其中有許多的解決方案是設計新的多媒體作業系統 (Multimedia Operating Systems) 來解決。

因為我們要實現 VOD 的技術，因此將會涉及網路的主題，所以要考慮的層面也會比較多。除了網路相關問題外，也會在底下一併討論其它幾個主要的大問題。

Video Streaming 的傳送問題

Video Conferencing 所遭遇到的第一個問題是如何遞送 (deliver) 影像串流 (video streams)，這其中又要考慮到串流的管理、與網際網路即時性 (real-time over the Internet) 問題。

Video Conferencing 重要的關鍵之一是在於如何有效縮短 latency。所以我們也必須尋找一個有效的方便，來適應各種不同網路頻寬的環境。

Video Streaming 的資料儲存問題

Video Streaming 的應用還要考慮的問題則是儲存設備 (storage) 的選擇。Video Streaming 的應用必須要有良好的儲存環境，來儲存各種型態的多媒體資料，包含：文字、影像、聲音、圖片等等，每種資料的特性都不相同。

檔案系統 (filesystem) 對於多媒體物件的管理也是很重要的因素之一，必須要有一個可以快速存取並且有效管理多媒體物件的檔案系統，才能滿足效能的需求。

作業系統的磁碟儲存

在現階段 Video Streaming 以至於多媒體應用程式的設計上，對於 OS 支援的磁碟排程 (Disk Scheduler) 也被列入我們考慮研究的項目之一。傳統上，一般我們設計 OS 時都會選擇 SCAN 或是 SSTF 演算法，不過這些傳統的磁碟排程演算法並無法滿足我們的需求。

較先進的磁碟排程演算法應考慮到 Video 與 Audio 的應用，而目前較普遍被選擇用來設計 multimedia I/O 系統的磁碟排程演算法則是 SCAN-EDF 演算法。

SCAN-EDF 演算是結合 SCAN 與 EDF 優點的解決方案，SCAN 是眾所皆知的 seek optimizing 磁碟排程演算法；而 EDF (Earliest Deadline First) 則是屬於 real-time scheduling 的演算法。

磁碟排程對於 Video Streaming 應用的影響

引進 SCAN-EDF 磁碟排程演算法的重要之處在於我們必須要能支援 real-time request，其影響的範圍包括：

• Maximum allowable streams

• Reponse time

SCAN-EDF 已被分析並證實可以改善以上的效能，那麼，對於目前廣受歡迎的 Linux 而言，由於 SCAN-EDF 已經早就在實作應用的範圍內了，我們可以將 SCAN-EDF 磁碟排程演算法加到 Linux kernel 裡。如此一來，Linux 在 Video Streaming 的應用上也算是重要的效能改良。

Video Conferencing 的 Synchronization 問題

當我們進行多方 (n-way) 視訊會議時，程式總不能讓每個人所看到的影像畫面都不相同吧！就算無法真正做到每個人的畫面同一時間都相同，但至少也要控制在合理可接受的範圍之內。

Synchronization (同步) 問題的研究主要是在建立互動式 (interactive) 的多媒體應用程式上，同步問題的解決是需要相當多的時間與精神的，好在目前有重量級的 toolkit 供我們使用，那就是 Nsync (in-sync)。

Nsync 共包含二大部份：

• Synchronization definition language

• Run-time presentation management system

當然我們的 Video Conferencing 應用程式當然也需要 Nsync 的幫忙！

程式補充包

底下我們將補充二個簡單的函數，供讀者使用，這二個函數與我們的範例程式並沒有直接關係，但在測試時可能會有機會使用到：

• jpeg.c：將擷取的影像資料利用 libjpeg 存成 JPEG 圖檔。

• ppm.c：將擷取的影像直接寫成 PPM 圖檔。

存成 JPEG 圖檔部份

檔案：jpeg.h
/*
* JoTV - Video Streaming Systems
* (c) 2001 Jollen <jollen@o3.net>
*/
#ifndef _JPEG_H_
#define _JPEG_H_

int write_jpeg(char *filename, IMG *img, int width, int height,
int quality, int gray);

#endif

檔案：jpeg.c
/*
* JoTV - Video Streaming Systems
*
* jpeg.c - output image to the jpeg files
* (c) 2001 Jollen <jollen@o3.net>
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <time.h>
#include <fcntl.h>
#include <unistd.h>
#include <ctype.h>
#include <jpeglib.h>
#include <jerror.h>
#include <jconfig.h>
#include <pthread.h>
#include <sys/param.h>
#include <sys/types.h>
#include "JoTV.h"

int write_jpeg(char *filename, IMG *img, int width, int height,
int quality, int gray)
{
struct jpeg_compress_struct jcfg;
struct jpeg_error_mgr jerr;
FILE *fp;
unsigned char *line;
int line_length;
int i;

if ((fp = fopen(filename,"wb")) == NULL) {
fprintf(stderr,"write_jpeg: can't open %s: %s\n", filename, strerror(errno));
return -1;
}

jcfg.err = jpeg_std_error(&jerr);
jpeg_create_compress(&jcfg);

jcfg.image_width = width;
jcfg.image_height = height;
jcfg.input_components = gray ? 1: 3; // 3 sample per pixel (RGB)
jcfg.in_color_space = gray ? JCS_GRAYSCALE: JCS_RGB;
jpeg_set_defaults(&jcfg); // problem ...

jpeg_stdio_dest(&jcfg, fp);

jpeg_set_quality(&jcfg, quality, TRUE);
jpeg_start_compress(&jcfg, TRUE);

line_length = gray ? width : width * 3;
line = (unsigned char *)img;

for (i = 0; i < height; i++, line += line_length)
jpeg_write_scanlines(&jcfg, &line, 1);

jpeg_finish_compress(&jcfg);
jpeg_destroy_compress(&jcfg);
fclose(fp);

return 0;
}

函數的呼叫方法如下，直接加到範例的主程式裡即可：

write_jpeg("JoTV.jpg", img, DEFAULT_WIDTH, DEFAULT_HEIGHT, 75, FALSE /*not grey*/);

中標=存成 PPM 圖檔部份

檔案：ppm.c
/*
* JoTV - Video Streaming Systems
*
* ppm.c - output image to the ppm file
* (c) 2001 Jollen <jollen@o3.net>
*/
int write_ppm(IMG *);

int write_ppm(IMG *img)
{
FILE *fp;

fp = fopen("test.ppm", "w");
fprintf(fp, "P6\n%d %d\n255\n", NTSC_WIDTH, NTSC_HEIGHT);
fwrite(img, NTSC_HEIGHT, 3*NTSC_WIDTH, fp);
fclose(fp);
}


數的呼叫方法如下，直接加到範例的主程式裡即可：

write_ppm(img);

圖檔會存成檔名：test.ppm，由於大部份的繪圖軟體對於 TIFF 的支援較好，所以可以再利用 ppm2tiff 工具將 PPM 圖檔轉成 TIFF 格式：

$ ppm2tiff test.ppm test.tif

Video Streaming 的應用實例

經過這一系列的 Linux Video Streaming 應用探討，我們已經可以有能力設計出許多簡單的 Video Streaming 應用程式。例如以 video4linux、bttv、rtp 和 jpeg 壓縮技術便能實作簡單的 Webcam 應用程式。

底下是我們利用 Java 實作出來的 Linux Webcam 應用程式，在遠端直接以瀏覽器來執行即可。


圖 1 利用 Java 與 Video Streaming 技術設計的 Linux Webcam


圖 2 利用 Java 與 Video Streaming 技術設計的 Linux Webcam

Webcam 與 CCD 結合的應用包括：遠距教學、視訊會議、安全監控…等等。

]]> https://www.jollen.org/blog/2001/10/linux_video_streaming_6.html https://www.jollen.org/blog/2001/10/linux_video_streaming_6.html GNU Toolchains & Linux Systems Programming Thu, 18 Oct 2001 12:06:00 +0800 www.jollen.org



mmap 的初始化從那裡開始

繼前四期介紹有關 Video Streaming 的內容後, 最近收到幾位讀者的來信, 詢問有關 video4linux 利用 mmap 擷取影像的方法。video4linux 以 mmap 擷取影像的方法在本文第 4 篇曾經簡單介紹過, 但是有讀者希望可以做更詳細的介紹, 因此筆者特別將相關的程式碼完整列出供參考。

要提到 mmap 的初始化, 我們要配合第 2 篇文章的程式範例。底下是對影像擷取裝置做初始化的程式碼, 與第 2 篇文章的範例比較, 底下的函數設計的更完整:

int device_init(char *dev, int channel, int norm)
{
int i;

if (dev == NULL) {
dev = "/dev/video0"; //set to default device
}

if (v4l_open(dev, &vd)) {
return -1;
} else {
v4l_grab_init(&vd, screen_width, screen_height); //wake up drivers!
v4l_close(&vd);
}

if (v4l_open(dev, &vd)) return -1;
if (v4l_get_channels(&vd)) return -1;
if (v4l_set_norm(&vd, norm)) return -1;
if (v4l_mmap_init(&vd)) return -1;
if (v4l_switch_channel(&vd, channel)) return -1;

printf("%s: initialization OK... %s\n"
"%d channels\n"
"%d audios\n\n", dev, vd.capability.name, vd.capability.channels, vd.capability.audios);

for (i = 0; i < vd.capability.channels; i++) {
printf("Channel %d: %s (%s)\n", i, vd.channel[i].name,
v4l_norms[vd.channel[i].norm].name);
}

printf("v4l: mmap's address = %p\n", vd.map);
printf("v4l: mmap's buffer size = 0x%x\n", vd.mbuf.size);
printf("v4l: mmap's frames = %d (%d max)\n", vd.mbuf.frames, VIDEO_MAX_FRAME);
for (i = 0; i < vd.mbuf.frames; i++) {
printf("v4l: frames %d's offset = 0x%x\n", i, vd.mbuf.offsets[i]);
}

printf("v4l: channel switch to %d (%s)\n", channel, vd.channel[channel].name);

// start initialize grab
if (v4l_get_picture(&vd)) return -1;
if (v4l_set_palette(&vd, DEFAULT_PALETTE)) return -1;
if (v4l_grab_init(&vd, screen_width, screen_height)) return -1;
if (v4l_grab_sync(&vd)) return -1;

return 0;
}

我們又把 device_init() 寫的更完整了。粗體字的地方是我們初始化 mmap 的程式碼, 一開始的程式可能又讓人覺得一臉汒然:

if (v4l_open(dev, &vd)) {
return -1;
} else {
v4l_grab_init(&vd, screen_width, screen_height); //wake up drivers!
v4l_close(&vd);
}

將 device 開啟成功後, 做了一次 v4l_grab_init 後再把 device 關掉, 用意何在呢? 其實, 是因為 bttv 的 driver 是以 module 的方式安裝到 Linux kernel, 所以 bttv driver 會因為沒有被使用, 而「睡覺了」。

我們加上一次 v4l_grab_init() 的目的就是為了要「叫醒」bttv 的 driver, 其實這個動作可有可無, 但一般認為加上會比較好。

v4l_mmap_init() 是對 mmap 做初始化的工作, 不過要特別注意, 這個動作要在 channel 與 norm 都設定好後才進行, 底下會再說明一次。

v4l_mmap_init() 相當重要, 因為我們要利用 mmap() 函數將 v4l_deivce 結構裡的 map「連接」起來。mmap() 是 POSIX.4 的標準函數, 用途是將 device 給 map 到記憶體, 也就是底下粗體字的地方:

int v4l_mmap_init(v4l_device *vd)
{
if (v4l_get_mbuf(vd) < 0)
return -1;

if ((vd->map = mmap(0, vd->mbuf.size, PROT_READ|PROT_WRITE, MAP_SHARED, vd->fd, 0)) < 0) {
perror("v4l_mmap_init:mmap");
return -1;
}
return 0;
}

PROT_READ 表示可讀取該 memory page , PROT_WRITE 則是可寫入, MAP_SHARED 則是讓這塊 mapping 的區域和其它 process 分享。第一個參數旦 0 是啟始位置, vd->mbuf.size 則是長度 (length)。vd->fd 則是 device 的 file description, 最後一個參數是 offset。

v4l_get_mbuf() 和之前介紹過的沒有什麼出入。在新的 device_init() 函數裡, 我們也把初始化好的 mmap 相關資訊印出。

channel 與 norm

我們提過, 在做 v4l_mmap_init() 前要先做 channel 與 norm 的設定, 分別是 v4l_get_channels() 與 v4l_set_norm() 函數。

在這裡要捕充說明一點, 以筆者的 CCD 頭來講, 和擷取卡是以 Composite1 連接, 所以在 channel 方面, 就要利用 v4l_switch_channel() 將 channel 切到 Composite1 端。

v4l_switch_channel() 程式碼如下:

int v4l_switch_channel(v4l_device *vd, int c)
{
if (ioctl(vd->fd, VIDIOCSCHAN, &(vd->channel[c])) < 0) {
perror("v4l_switch_channel:");
return -1;
}
return 0;
}

傳入的 c 是 channel, 而 channel number 我們已經在 device_init() 裡列印出來:

Channel 0: Television
Channel 1: Composite1
Channel 2: S-Video

我們可以看到 Composite1 位於 Channel 1 (由 0 算起), 所以 v4l_switch_channel() 的參數 c 要傳入 1。

如何設定 norm

norm 的話就比較單純一點, 參數如下:

VIDEO_MODE_PAL
VIDEO_MODE_NTSC
VIDEO_MODE_SECAM
VIDEO_MODE_AUTO

這些參數都定義於 videodev.h 檔案裡。v4l_set_norm() 是我們用來設定 norm 的函數, 程式碼如下:

int v4l_set_norm(v4l_device *vd, int norm)
{
int i;

for (i = 0; i < vd->capability.channels; i++) {
vd->channel[i].norm = norm;
}

if (v4l_get_capability(vd)) {
perror("v4l_set_norm");
return -1;
}
if (v4l_get_picture(vd)) {
perror("v4l_set_norm");
}
return 0;
}

要仔細注意, 我們是對所有的 channel 設定 norm, 設定完成後, 底下又做了一次 v4l_get_capability(), 主要目的是確保每個 channel 的設定都有被設定成功。然後呼叫 v4l_get_picture。

v4l_get_capability() 會利用 ioctl() 取得設備檔的相關資訊，並且將取得的資訊放到 struct video_capability 結構裡。同理，v4l_get_picture() 也會呼叫 ioctl() ，並將影像視窗資訊放到 struct video_picture 結構。

如何 get picture

取得設備資訊後，我們還要再取得影像資訊，所謂的影像資訊指的是輸入到影像捕捉卡的影像格式。

在 _v4l_struct 結構裡，我們宣告 channel 如下：

struct video_picture picture;

初始化 picture 的意思就是要取得輸入到影像捕捉卡的影像資訊，我們設計 v4l_get_ picture() 函數來完成這件工作。

v4l_get_ picture () 完整程式碼如下：

int v4l_get_picture(v4l_device *vd)
{
if (ioctl(vd->fd, VIDIOCGPICT, &(vd->picture)) < 0) {
perror("v4l_get_picture:");
return -1;
}
return 0;
}

傳遞VIDIOCGPICT 給 ioctl() 則會傳回影像的屬性 (image properties)，這裡則是將影像屬性存放於 vd-> picture。

這部份我們也曾經介紹過, 在這裡要再捕充一點。如果是以 GREY 方式擷取影像, 那麼我們可以利用 VIDIOCSPIC 來設定像素的亮度與灰階度, 請參考 API.html 裡的 struct video_picture 說明。

初始化 grab

初始化 grab 的程式碼如下:

if (v4l_get_picture(&vd)) return -1;
if (v4l_set_palette(&vd, DEFAULT_PALETTE)) return -1;
if (v4l_grab_init(&vd, screen_width, screen_height)) return -1;
if (v4l_grab_sync(&vd)) return -1;

v4l_get_picture() 與之前介紹的一樣, 而 v4l_set_palette() 則是用來設定調色盤, 由於我們希望得到的是 RGB32, 所以 DEFAULT_PALETTE 定義成:

#define DEFAULT_PALETTE VIDEO_PALETTE_RGB32

如果沒有硬體轉換, 前一篇文章 (4) 我們也提到將 YUV (PAL) 轉成 RGB 的方法了。再來將就是對 grab 做初始化, v4l_grab_init()

int v4l_grab_init(v4l_device *vd, int width, int height)
{
vd->mmap.width = width;
vd->mmap.height = height;
vd->mmap.format = vd->picture.palette;
vd->frame_current = 0;
vd->frame_using[0] = FALSE;
vd->frame_using[1] = FALSE;

return v4l_grab_frame(vd, 0);
}

初始化的目的是將 mmap 結構填入適當的值。針對 RGB32、NTSC 的 CCD 影像擷取, mmap 的大小不妨設定成 640*480 或 320*240 都可以, 給定 mmap 的大小後, 再來還要將 format 填入調色盤類型。

最後設定 frame_current 變數與 frame_using[] 陣列, 這裡等於上一篇 (4) 介紹的 frame 變數與 framestat[] 陣列。

如何所有的程式碼都沒有錯誤, 當裝置正常軀動時, 就可以看到底下的初始化訊息, 這裡的訊息比起之前的範例更清楚、完整:

/dev/video0: initialization OK... BT878(Chronos Video Shuttle I)
3 channels
3 audios

Channel 0: Television (NTSC)
Channel 1: Composite1 (NTSC)
Channel 2: S-Video (NTSC)
v4l: mmap's address = 0x40173000
v4l: mmap's buffer size = 0x410000
v4l: mmap's frames = 2 (32 max)
v4l: frames 0's offset = 0x0
v4l: frames 1's offset = 0x208000
v4l: channel switch to 1 (Composite1)

Image pointer: 0x4037b000

v4l_grab_frame() 的用處

讀者可能還不明白 v4l_grab_frame() 的用途, v4l_grab_frame() 是真正將影像放到 mmap 裡的函數。

我們重寫一次 v4l_grab_frame() 函數, 並且再說明一次:

int v4l_grab_frame(v4l_device *vd, int frame)
{
if (vd->frame_using[frame]) {
fprintf(stderr, "v4l_grab_frame: frame %d is already used.\n", frame);
return -1;
}

vd->mmap.frame = frame;
if (ioctl(vd->fd, VIDIOCMCAPTURE, &(vd->mmap)) < 0) {
perror("v4l_grab_frame");
return -1;
}
vd->frame_using[frame] = TRUE;
vd->frame_current = frame;
return 0;
}

因為我們用 frame_using[] 陣列來紀錄那個 frame 已經被使用, 所以一開始當然要先判斷目前的 frame 是否已經被使用:

if (vd->frame_using[frame]) {
fprintf(stderr, "v4l_grab_frame: frame %d is already used.\n", frame);
return -1;
}

如果沒有被使用, 就把 mmap 的 frame 填入 frame 編號, 然後利用 VIDIOCMCAPTURE 擷取出影像。結束前要把目前 frame 的狀態標示成使用中 (frame_using[]), 然後把 frame_current 指定成現在的 frame, 完成工作後離開。

mmap 如何做 filp-flop

這是一位讀者問的問題。這個問題問的相當聰明, 每個人可能都有不同的方法來做 flip-flop 的動作, 這裡筆者以 2 個 frame 為例, 我們可以再寫一個函數來做 flip-flop:

int device_grab_frame()
{
vd.frame_current = 0;

if (v4l_grab_frame(&vd, 0) < 0)
return -1;

return 0;
}

int device_next_frame()
{
vd.frame_current ^= 1;
if (v4l_grab_frame(&vd, vd.frame_current) < 0)
return -1;

return 0;
}

device_next_frame() 是主要核心所在, 因為我們只有二個 frame, 所以 frame_current 不是 0 就是 1。

擷取出來的影像放在那裡

因為我們特別寫了上面的函數來做 mmap 的 flip-flop, 所以在主程式裡就改用 device_next_frame 來持續擷取影像。

所以配合主程式, 我們的程式寫法如下:

device_next_frame(); //Ok, grab a frame.
device_grab_sync(); //Wait until captured.

img = device_get_address(); //Get image pointer.
printf("\nImage pointer: %p\n", img);

這段程式就是我們的重點好戲, 當我們呼叫 device_next_frame() 擷取 frame 之後, 必須做一個等待的動作, 讓 frame 擷取完成再取出影像。

v4l_grab_sync() 程式碼如下:

int v4l_grab_sync(v4l_device *vd)
{
if (ioctl(vd->fd, VIDIOCSYNC, &(vd->frame_current)) < 0) {
perror("v4l_grab_sync");
}
vd->frame_using[vd->frame_current] = FALSE;
return 0;
}

利用 VIDIOCSSYNC 等待完成後, 別忘了將目前 frame 的狀態改回未被使用。接下來我們要問, 擷出出來的 frame 到底放到那裡去了呢?

答案就是之們利用 mmap() 將 device 所 map 的記憶體裡, 因為我們是利用 mmap (flip-flop) 方式, 所以會有 2 個 (或以上) 的 frame, 這時就要計算一下 offset, 才知道到底目前的影像資料被放到那裡了。

算式如下:

vd.map + vd.mbuf.offsets[vd.frame_current]

device_get_address() 函數就是這麼回事。

如何輸出影像資料呢

輸出影像資料的方法很多, 可以直接輸出到 framebuffer 上, 或是利用 SDL 顯示。在這裡筆者要示範最原始的方法 – 輸出到檔案裡。

當我們利用 device_get_address() 取得 frame 的影像資料後, 再將 frame 的影像資料輸出成 PPM 格式的檔案。

程式碼如下:

FILE *fp;

fp = fopen("test.ppm", "w");
fprintf(fp, "P6\n%d %d\n255\n", NTSC_WIDTH, NTSC_HEIGHT);
fwrite(img, NTSC_WIDTH, 3*NTSC_HEIGHT, fp);
fclose(fp);

先利用 fprintf() 寫入 PPM 檔案的檔頭資訊, 然後以 fwrite() 將傳回的影像資料寫到檔案裡。

img 指向記憶體裡的 frame 影像資料, 寫入時, 請特別注意粗體字的地方, 因為我們是用 RGB32 的調色盤, 而 RGB 是以 3 個 sample 來表示一個 pixel, 所以要乘上 3。

如果是 GREY 調色盤, 就不用再乘 3 了。最後將輸出的 PPM 檔案轉換格式成 TIFF 就可以用一盤的繪圖軟體打開了:

linux$ ppm2tiff test.ppm test.tiff

將影像存成 JPEG 的方法

最後我們再完成一個功能, 就可以實作出一個完整的 Webcam 軟體。之前我們將影像存成 PPM 格式的圖檔, 不過因為檔案過太, 會造成傳輸的不便。因此, 我們勢必要將影像資料存成更小的檔案才具實用性。

JPEG 或MJPEG 都是在本文第 1 篇介紹過的格式。以 JPEG 來存放圖檔, 相當容易可以實作出 Webcam 的功能, 但缺點就是無法傳送聲音資料。

我們使用 mpeglib 來完成這項任務, mpeglib 可至 www.ijg.org 下載。

將影像資料存成 JPEG 的方法在「各大」與 video streaming 有關的軟體 (例如: xawtv) 都可以看得到範例。不過因此這部份已脫離 v4l 的主, 所以筆者只列出底下的 write_jpeg() 完整函數, 供讀者使用:

int write_jpeg(char *filename, unsigned char * img, int width, int height, int quality, int gray)
{
struct jpeg_compress_struct jcfg;
struct jpeg_error_mgr jerr;
FILE *fp;
unsigned char *line;
int line_length;
int i;

if ((fp = fopen(filename,"w")) == NULL) {
fprintf(stderr,"write_jpeg: can't open %s: %s\n", filename, strerror(errno));
return -1;
}

jcfg.image_width = width;
jcfg.image_height = height;
jcfg.input_components = gray ? 1: 3; // 3 sample per pixel (RGB)
jcfg.in_color_space = gray ? JCS_GRAYSCALE: JCS_RGB;
jcfg.err = jpeg_std_error(&jerr);

jpeg_create_compress(&jcfg);
jpeg_stdio_dest(&jcfg, fp);

jpeg_set_defaults(&jcfg);
jpeg_set_quality(&jcfg, quality, TRUE);
jpeg_start_compress(&jcfg, TRUE);

line_length = gray ? width : width * 3;
for (i = 0, line = img; i < height; i++, line += line_length)
jpeg_write_scanlines(&jcfg, &line, 1);

jpeg_finish_compress(&jcfg);
jpeg_destroy_compress(&jcfg);
fclose(fp);

return 0;
}

利用 mpeglib 寫入 JPEG 影像資料時, 必須分別對每行 scanline 寫入。呼叫範例:

write_jpeg("test01.jpg", img, NTSC_WIDTH, NTSC_HEIGHT, 50, FALSE );

第一個參數是圖檔名稱, 第二個參數是影像資料, 然後第三、第四個參數接著影像的大小, 第五個參數 50 表示 JPEG 圖檔的壓縮品質 (quality), 最後一個參數 FALSE 表示影像資料不是 grey (灰階) 影像。

灰階影像與彩色影像的差別在於 input_components、in_color_space 與 scanline 的長度。

結語

在一連串的 Video Streaming 主題裡, 我們學到 video4linux 擷取影像的方式, 以 mmap (flip-flop) 來連續擷取影像, 並做到 VOD 的功能是我們的最終目的。到這裡為止, 我們已經有能力實作出簡單的 Webcam 軟體, 類似這種取固定間隔傳送影像的方式應用也很廣, 例如路口交通狀況回報。

利用到這裡所學的方法, 將擷取的影像存成 JPEG, 然後放到 Web 上, 固定一段時間更新, 我們也可以設計一套簡單的路口交通狀況回報系統, 或是家裡的監視系統。

後面接著的主題, 將會以現有的程式為基礎, 實作真正具有 VOD 能力的軟體。

]]> https://www.jollen.org/blog/2001/09/linux_video_streaming_5.html https://www.jollen.org/blog/2001/09/linux_video_streaming_5.html GNU Toolchains & Linux Systems Programming Fri, 14 Sep 2001 08:31:00 +0800 www.jollen.org



video4linux 擷取 frame 的方法

在上一期的 xawtv 裡, 我們看到了 xawtv 的影像擷取功能, 其中對我們最重要的部份是利用 video4linux 做影像擷取的部份。

只要可以寫出 video4linux 的軀動部份, 要做影像擷取其實是很容易的, 我們利用的是 mmap 的方式來擷取影像。

mmap 擷取方式

為了說明如何以 mmap 方式來擷取影像, 我們不建議讀者直接去研究 xawtv 關於這部份的程式碼。研究過幾個有關支援 mmap 影像擷取的軟體原始碼後, 我們建議讀者去下載一支名為 EffecTV 的程式, 其官方網頁為:

http://effectv.sourceforge.net/index.html

EffecTV 是日本人設計的程式, 也是經由 video4linux 做影像擷取, 在 mmap 的程式碼方面, EffecTV 會比較容易懂, 同時也可以藉由 EffecTV 來學習一些影像處理的技巧。

EffecTV 是一個可以支援特效功能的視訊軟體, 是頗有趣的程式。

主要函數介紹

EffecTV 裡與影像擷取 (frame grab) 有關的函數為:

int video_grab_check(int palette);
int video_set_grabformat();
int video_grabstart();
int video_grabstop();
int video_syncframe();
int video_grabframe();

這些函數定義在 video.h 裡。我們不再重覆介紹 video4linux 初始化的地方, 在 frame grab 方面, 呼叫 video_grabstart() 開始進行影像擷取的工作, 程式碼如下:

/* Start the continuous grabbing */
int video_grabstart()
{
vd.frame = 0;
if(v4lgrabstart(&vd, 0) < 0)
return -1;
if(v4lgrabstart(&vd, 1) < 0)
return -1;
return 0;
}

其中主角是 v4lgrabstart() 函數, 這個函數被實作在 v4lutils/v4lutils.c 裡, 程式碼如下:

/*
* v4lgrabstart - activate mmap capturing
*
* vd: v4l device object
* frame: frame number for storing captured image
*/
int v4lgrabstart(v4ldevice *vd, int frame)
{
if(v4l_debug) fprintf(stderr, "v4lgrabstart: grab frame %d.\n",frame);
if(vd->framestat[frame]) {
fprintf(stderr, "v4lgrabstart: frame %d is already used to grab.\n", frame);
}
vd->mmap.frame = frame;
if(ioctl(vd->fd, VIDIOCMCAPTURE, &(vd->mmap)) < 0) {
v4lperror("v4lgrabstart:VIDIOCMCAPTURE");
return -1;
}
vd->framestat[frame] = 1;
return 0;
}

v4lgrabstart() 是利用 mmap 的方式來取得影像。v4lgrabstart() 也是利用 ioctl() 來完成這個低階的動作, 與第本文第二篇實作 video4linux 時一樣, 寫法為:

ioctl(vd->fd, VIDIOCMCAPTURE, &(vd->mmap));

vd 裡的 framestat 欄位主要是紀錄目前的 frame 狀態:

vd->framestat[frame]

這個欄位定義在 v4lutils.h 裡, 而利用 mmap 的方式我們需要兩個 frame 來存放影像資料, 所以 framestat 宣告成二個元素的陣列, 我們將 EffecTV 的 v4l 結構定義完整列出如下:

struct _v4ldevice
{
int fd;
struct video_capability capability;
struct video_channel channel[10];
struct video_picture picture;
struct video_clip clip;
struct video_window window;
struct video_capture capture;
struct video_buffer buffer;
struct video_mmap mmap;
struct video_mbuf mbuf;
struct video_unit unit;
unsigned char *map;
pthread_mutex_t mutex;
int frame;
int framestat[2];
int overlay;
};

請讀者回頭對應一下本文第二篇文章所實作的內容, EffecTV 的實作更為完整。

當我們開始 grab 影像到其中一個 frame 時, 我們就把 frame 的狀態設成 1:

vd->framestat[frame] = 1;

然後利用 v4lsync() 等待 frame 擷取完成, 利用 ioctl() 傳入 VIDIOCSYNC 可以檢查 frame 是否已經擷取完成:

if(ioctl(vd->fd, VIDIOCSYNC, &frame) < 0) {
v4lperror("v4lsync:VIDIOCSYNC");
return -1;
}
vd->framestat[frame] = 0;
return 0;

如果 frame 已擷取完成, 那麼我們就將 frame 的狀態設成 0, 表示目前這個 frame 並沒有在做擷取的動作, 也因此在 v4lsync() 一開始的地方我們會先做這部份的檢查:

if(vd->framestat[frame] == 0) {
fprintf(stderr, "v4lsync: grabbing to frame %d is not started.\n", frame);
}

v4lsync() 函數也是一個重要的函數, 程式碼如下:

/*
* v4lsync - wait until mmap capturing of the frame is finished
*
* vd: v4l device object
* frame: frame number
*/
int v4lsync(v4ldevice *vd, int frame)
{
if(v4l_debug) fprintf(stderr, "v4lsync: sync frame %d.\n",frame);
if(vd->framestat[frame] == 0) {
fprintf(stderr, "v4lsync: grabbing to frame %d is not started.\n", frame);
}
if(ioctl(vd->fd, VIDIOCSYNC, &frame) < 0) {
v4lperror("v4lsync:VIDIOCSYNC");
return -1;
}
vd->framestat[frame] = 0;
return 0;
}

在 EffecTV 裡則是要呼叫 video_syncframe() 函數來做 frame 等待的動作, 而 video_syncframe() 則會去呼叫 v4lsync() 函數。video_syncframe() 函數的原始碼如下:

int video_syncframe()
{
return v4lsyncf(&vd);
}

frame 擷取實作

看過這幾個核心函數後, 那麼在 EffecTV 裡會在那裡用到這些函數呢? EffecTV 是一個輸出特效畫面的視訊軟體, 在 effects/ 目錄下每個檔案都是獨立支援一種特效的, 因此我們介紹的這幾個函數都是由每個特效獨立來呼叫使用。

讓我們來看 Life 這個特效的主程式 – life.c, 首先應該先由 lifeStart() 函數看起, 其程式碼如下:

int lifeStart()
{
screen_clear(0);
image_stretching_buffer_clear(0);
image_set_threshold_y(40);
field1 = field;
field2 = field + video_area;
clear_field();
if(video_grabstart())
return -1;

stat = 1;
return 0;
}

lifeStart() 在完成一些初始化的設定工作後, 會呼叫 video_grabstart() 函數開始進行影像擷取。在 lifeDraw() 函數裡, 則是呼叫 video_syncframe() 等待 frame 擷取完成後再做輸出的動作。

YUV 與 YIQ

在 PAL 視訊標準方面, 主要的模式為 YUV, 這與我們在電腦上常用的 RGB 不同。相對的, 在 NTSC 視訊標準, 則是使用 YIQ 模式。

針對這二種視訊影像模式, 我們還必須設計 YUV 與 RGB、YIQ 與 RGB 的轉換程式。在 EffecTV 裡也有 yuv.c 的程式碼負責做轉換的工作。

RGB 介紹

RGB 以三原色紅、綠、藍 (Red-Green-Blue) 來表現影像, 將紅色與藍色重疊後會成為品紅色 (magenta)、紅色與綠色重成為黃色 (yellow), 三色重疊則是白色 (white)。

RGB 的三原色指的是光線的顏色, 並非顏料的顏色, RGB 模式常使用於監視器上, 與 PAL 或 NTSC 視訊的標準不同。

YUV 與 YIQ 的轉換

YUV 、 YIQ 與 RGB 之間的換係與轉換公式如下:

Y = 0.299R + 0.587G + 0.114B
U = B – Y
V = R – Y
I = 0.877(R-Y)cos33 – 0.492(B-Y)sin33
Q = 0.877(R-Y)sin33 + 0.492(B-Y)cos33

RGB 是由 R, G, B 三原色組成, 同理 YUV 是由 Y, U, V 三個元素組成。在 PAL 實作 U, V 我們使用的轉換公式為:

U = 0.492(B-Y)
V = 0.877(R-Y)

YIQ 則可以簡化成轉換矩陣:

(手稿)

JRTPLIB 的使用方法

在 Video Streaming 方面, 有了影像擷取的程式實作能力後, 要完成完整的影像串流軟體, 例如視訊會議軟體, 當然就必須要加入網路傳送的功能。

為了能利用網路傳送影像, 並且做到 real-time (即時) 的功能, 我們必須使用 RTP 通訊協定來完成。在這裡我們已經完成第一大部份的工作了, 接下來就是加入網路即時傳送撥放的功能, 到這裡 video4linux 已告一段落, 我們將 Video Streaming 的主角換到 RTP 繼續討論。

加入 RTP Protocol

利用 Video Streaming 來設計視訊會議軟體, 其中在技術層面不可或缺的一部份就是 RTP Protocol 的部份。RTP 也是 VoIP (Voice over IP) 相關技術所使用的通訊協定。

為了配合 Video Streaming 來設計完整的視訊會議軟體, 我們勢必要加入 RTP 的技術。在這方面, 我們選擇使用現成的 RTP 程式庫 – JRTPLIB。

與 video4linux 程式庫不同的是, video4linux 在決策上我們選擇自行發展, 但 JRTPLIB 則是一個很成熟的專案了, 而且仍在持續維護, 未來 JRTPLIB 還會加入 IPV6 與 multicasting 方面的完整支援, 因此使用 JRTPLIB 來發展我們的 Video Streaming 軟體才是解決之道。

JRTPLIB 簡介

RTP 全名為 Real-time Transport Protocol, 定義於 RFC 1889 與 RFC 1890, 我們在第一篇文章裡已經簡單介紹過 RTP。

在 RFC 1889 裡, 對 RTP 的定義為:

RTP: A Transport Protocol for Real-Time Applications

而在 RFC 1890 裡, 對 RTP 的描述則是:

RTP Profile for Audio and Video Conferences with Minimal Control

即然我們要利用 Video Streaming 來設計視訊會議方面的軟體, 對於 RTP 的討論與研究則是必修功課之一。對視訊會議軟體而言, RTP 也提供 Audio 部份的支援, 事實上, 任何與 real-time (即時) 相關的話題都與 RTP 脫不了關係。

與 JRTPLIB 相關的計畫包括 JVOIPLIB 與 JTHREAD, 這兩個程式庫對我們的工作是相關有幫助的, 本文則先將重心放在 JRTPLIB上面。

JRTPLIB 實作了 RTP 協定, 並且提供了簡單易用的 API 供軟體開發使用。JRTPLIB 也支援了 session, 並且可在底下平臺執行:

• MS-Windows 95,98 and NT
• Linux
• FreeBSD
• HP-UX
• Solaris
• VxWorks

JRTPLIB 的官方首頁為:

http://lumumba.luc.ac.be/jori/jrtplib/jrtplib.html

使用前請務必先閱讀一下 JRTPLIB 的版權宣告。

JRTPLIB 的第一個程式

底下我們介紹過 JRTPLIB 的設計方法後, 大家就會發覺到 JRTPLIB 實在很好上手。要利用 RTP 通訊協定傳送資料, 第一步要先建立一個 session, 方法如下:

#include "rtpsession.h"

int main(void)
{
RTPSession sess;

sess.Create(5000);
return 0;
}

第一步我們要先把 rtpsession.h 給 include 進來:

#include "rtpsession.h"

接下來再產生 RTPSession 類別的物件:

RTPSession sess;

最後再建立 session 就完成最簡單的初始動作了:

sess.Create(5000);

Create() 成員函數接收一個 portbase 的參數, 指定 session 的 port, 接著開始初始化 timestamp 與 packet sequence number。RTPSession::Create() 程式碼如下:

int RTPSession::Create(int localportbase,unsigned long localip)
{
int status;

if (initialized)
return ERR_RTP_SESSIONALREADYINITIALIZED;
if ((status = rtpconn.Create(localportbase,localip)) < 0)
return status;
if ((status = contribsources.CreateLocalCNAME()) < 0)
{
rtpconn.Destroy();
return status;
}
CreateNewSSRC();
localinf.CreateSessionParameters();
rtcpmodule.Initialize();
initialized = true;
return 0;
}

Create() 接著會再建立一個 SSRC:

CreateNewSSRC();

SSRC 為 local synchronization source identifier。

指定目的端

接下來再指定目的端的 IP 位址:

unsigned long addr = ntohl(inet_addr("127.0.0.1"));
sess.AddDestination(addr,5000);

這裡表示我們要將封包傳送到 127.0.0.1 (本地端) 的 port 5000, 只要照著套用即可。

傳送 RTP 封包

sess.SendPacket("1234567890",10,0,false,10);

1234567890 是要傳送的字串, 第二個參數 (10) 表示傳送字串的長度, 第三個參數為 payload type, 第四個參數為 mark flag, 最後第五個參數則是 timestamp 的遞增單位。

在下一期裡, 我們將會配合 SDL 來做影像的輸出, 因此我們會在下一期再介紹如何接收 RTP 封包。我們使用 SDL 主要目的是為了將影像輸出到螢幕上。

RTP 的封包格式

RTP 的標準受許多大廠採用, 例如: Microsoft、Intel, 也因此我們需要了解一下 RTP 的低層技術部份。

RTP 與其它 Internet 通訊協定一樣, 在封包裡也會有封包檔頭, 接著才是封包的資料。


圖 1 是 RTP 的封包檔頭格式, 整個檔頭分為 10 個欄位 (field)。

在 RTPsession::SendPacket() 的第三個參數與第四個參數分別是 payload type 與 mark flag, 在 RTP 封包檔頭裡, 分別是 Payload 欄位與 M 欄位。

Payload 欄位的長度為 7 bits, M 欄位的長度為 1 bits。

RTP 的 Payload type

RTP 檔頭的 Payload type 指定封包資料的編碼方式, 我們列出五個常用的 Audio 標準, 與三個常用的 Video 標準, 其中 JPEG/H.261/H.263 我們本文第一篇裡都有做過簡單的介紹。常用的 Payload type 如下表:

Payload type	編碼標準	支援Audio或Video	Clock Rate (Hz)
2	G.721	A	8000
4	G.723	A	8000
7	LPC	A	8000
9	G.722	A	8000
15	G.728	A	8000
26	JPEG	V	90000
31	H.261	V	90000
34	H.263	V	90000

Linux 的 IP Stacks

提要網路的應用, 當然也要對 Linux IP Stacks 有簡單的認識, 我們建議大家直接去研究 Linux kernel 的程式碼, 當然現在已經有專門的書在做討論:

Linux IP Stacks Commentary, Stephen T. Satchell & H.B.J. Clifford, CoriolisOpen Press, ISBN 1-57610-470-2

Linux 是網路作業系統, 而且 Linux 對於網路的支援也相當的完整, 包括2.4 系列 kernel 已經加入對 IPv6。 Linux kernel 與 module 提供的通訊層功能包括：

• 各種 Ethernet、token ring 與 FDDI (Fiber Distributed Data Interface) 介面卡的軀動程式
• PPP、SLIP 與 SLIP 通訊協定的軀動程式
• 提供 IPX (Internet Package Exchange) 通訊協定
• 提供業餘無線電用的軀動程式 (AX25)
• 提供 AppleTalk 軀動程式
• 其它連結層使用的軀動程式
• 支援 router 的功能，包括 RIP (Router Information Protocol) 通訊協定
• 支援 ICMP (Internet Control Message Protocol) 通訊協定
• 支援 IGMP (Internet Group Message Protocol) 通訊協定
• 支援 IP (Internet Protocol) 通訊協定
• 支援 TCP (Transmission Control Protocol) 通訊協定
• 支援 UDP (User Datagram Protocol) 通訊協定

inux IP Stacks 一書的書點放在基本與重要的 TCP/IP 服務上, 包含：遶送、封包管理、datagram 與 datastream。

Linux IP Stacks 導讀

裡的導讀參考自 Linux IP Stacks 一書的第一章, 在研究 Linux IP Stacks 這本書前, 請讀者先好好研究一下這本書的結構, 到時才比較容易上手。

第二章的部份介紹 TCP/IP 的背景知識與歷史，包括 TCP/IP 的發展過程, 這一章原則上只要了解一下即可。

第三章則以學術的觀點來比較 TCP/IP 與 ISO 模型。這一章比較偏向 ISO 的理論，而書上解釋到, 要學習 ISO 模型理論的目的, 是為了能夠了解為什麼通訊層要分割成這幾層。

]]> https://www.jollen.org/blog/2001/08/linux_video_streaming_4.html https://www.jollen.org/blog/2001/08/linux_video_streaming_4.html GNU Toolchains & Linux Systems Programming Mon, 13 Aug 2001 03:32:00 +0800 www.jollen.org)

什麼是影像擷取卡

影像擷取卡的主要功能當然就是做影像的擷取了, 一張影像擷取卡應該擁有底下的基本功能。

影像擷取

影像擷取卡可擷取的影像頁框 (frame) 的大小是很重要的, 本文第一篇裡提到的幾個基本影像頁框大小都應該要支援, 包含 NTSC (640x480) 與 PAL (768x576)。

影像擷取卡所捕捉的畫面都是屬於動態的畫面, 影像的來源則要看所支援的視訊系統與所有的視訊裝置。

支援的視訊系統

大部份影像擷取卡都會具備一組視訊輸入端子, 即 S-Video (Y/C) 端子或 Composite 端子。

在台灣的標準當然是 NTSC 系統, 一般而言, 我們是希望一張影像擷取卡可以支援越多視訊系統越好, 包括: NTSC/PAL/PALN/PLAM/SECAM。

可使用的視訊裝置有較常見的 CCD, 或是家用 V8、Hi8 皆可, 一般而言我們也是希望一張影像擷取卡可以接越多視訊裝置越好。

安裝影像擷取卡

以筆者的影像擷取卡為例，使用的是 Chronos Video Shuttle I 的卡，所以只要安裝 bttv 模組即可，同時，bttv 模組在 Linux kernel 2.2.17 下也會用到 i2c-old 與 videodev 兩個模組，所以也要一併安裝。在命令列下，安裝這三個模組的命令為：

linux# insmod i2c-old
linux# insmod videodev
linux# insmod bttv

當然要確定 Linux kernel 有編譯這三個模組的支援，然後再把這三個模組加到 /etc/modules.conf (Red Hat 7.0) 裡。

如果是使用 Linux kernel 2.4.x (如 Red Hat Linux 7.1), 也可以直接在 /etc/modules.conf 裡加上一行:

alias char-major-81 bttv

就可以了。然後再利用上一篇文章 (2) 的程式來做初始化, 可以看到底下的訊息:

/dev/video0: initialization OK... BT878(Chronos Video Shuttle I)
3 channels
3 audios

OK!

BT878 晶片初始化成功, 影象擷取卡名稱為 Chronos Video Shuttle I, 成功找到並初始化 3 個 channel。

bttv 模組就是底下會提到的 BTTV 軀動程式, 主要用途是軀動影像擷取卡上的 BT848/BT878 晶片。

影像擷取卡的應用

在 PC 上加裝影像擷取卡, 就可以利用 PC 做影片剪輯的工作, 例如可以將類比的 V8 影片轉換成數位影像, 並且儲存到電腦裡, 或製作成光碟保存。

配合這類的軟體, 我們還可以 DIY 做影像的特效、轉場特效、字幕、旁白等等。利用 PC 做影像剪輯的工是很耗電腦資源的, 所以不能用太陽春的 PC, 不然可以會很累人的！

壓縮比

壓縮比是判斷一張影像擷取卡優劣的主要關鍵所在, 由於動態的影像所佔用的空間相當大, 所以如果一張影像擷取卡無法有效將擷取出來的影像做壓縮, 所需的硬碟空間都會相當驚人。

壓縮比越好的影像擷取卡, 其工作效能越佳, 一般壓縮比大約是 4:1, 使用壓縮比越好的晶片, 當然也就越貴, 所以影像擷取卡是一分錢一分貨的。

BT 878 晶片

目前大部份的數位影像擷取卡大部份都是以 BT878 單顆晶片為影像擷取卡之中心。BT878 運作方式是以軟體來進行影像解壓縮工作, BT878 晶片負責將擷取之影像丟給 Linux 做影像處理, 而 BTTV 則是 Linux kernel 的 BT878 晶片軀動程式。

由於影像是利用 BT878 擷取後交由軟體來做影像處理, 因此在處理效能上自然就會比較差。如果是經由網路來傳送影像的話, 我們就會再利用影像壓縮技術 (H.261/H.263...等等) 來做影像處理。

什麼是 BTTV

BTTV 是 Linux 上的 Bt848/849/878/879 晶片的軀動程式, 主要功能是做頁框
的截取 (frame grabber)。

BTTV 是 video4linux 裡重要的軀動程式, 目前分為二個版本:

• 0.8.x 的發展中版本
• 0.7.x 的穩定版本

Linux 上可用的影像擷取卡

在http://www.linhardware.com/db/searchproduct.cgi?_catid=17 網頁上可以找到在 Linux 上支援程度比較好的幾張影像擷取卡。而一般 Linux 上較受歡迎的影像擷取卡則是 Hauppauge 的幾張卡, 筆者使用的也是 Hauppauge 的卡。

在 linhardware 網站上可以找到底下六張卡:

• Hauppauge 401 WinTV-radio dbx-TV stereo
• Hauppauge WinTV PCI TV Card
• Hauppauge WinTV-GO PCI TV Card
• Hauppauge WinTV-PCI Hauppauge
• Hauppauge WinTV-Radio+NICAM
• Hauppauge WinTV/PCI TV Card

關於 Linux 對於影像捕捉卡支援的中文文件 (HOWTO) 可以在 CLDP 網站上取得:

http://www.linux.org.tw/CLDP/Hardware-HOWTO-22.html

BTTV 相關軟體 - xawtv

官方網站: http://bytesex.org/xawtv/index.html

安裝方式:

1. linux# ./configure
2. linux# make depend
3. linux# make
4. linux# make install

如果您有 Red Hat Linux 7.1 PowerTools 光碟片的話, 也可以直接由 PowerTools 光碟片安裝 xawtv 套件:

linux# rpm -ivh xawtv-3.34-1.i386.rpm

安裝 xawtv 需要 libjpeg 與 libjpeg-devel 套件, 如果您是使用 Red Hat Linux 7.1 的話, 應該安裝底下二個套件:

libjpeg-6b-15.i386.rpm (Disc 1)
libjpeg-devel-6b-15.i386.rpm (Disc 2)

xawtv 整個架構可以分成 7 個部份如下:

• xawtv: 主程式部份。
• fbtv: linux console 模式的 TV 應用程式, 使用 linux kernel 2.2.x 的 framebuffer。
• set-tv: 命令列模式的工具, 用來設定 video4linux 的參數。
• streamer: 命令列模式的工具, 用來捉取動態影像與 avi 影像。
• radio: radio 應用程式。
• webcam: 將捉取的影像以 FTP 方式上傳到 Web Server 端, 用來設計 Web 即時影像的工具。
• alevtd: videotext pages 的 Web Server。

xawtv 的 video4linux

xawtv 是相當好的 video4linux 方面的教材, 在上一期我們看過一遍 video4linux 的設計方法後, 接下來我們要先捨棄我們上一期所實作的 video4linux 程式庫!

因為我們將要帶導大家研究 xawtv 裡以 video4linux API 設計的影像捕捉 (grab) 部份的程式碼, 這個程式碼的實作更完整, 因此在開始進入這個主題前, 必須先理解上一期所介紹的內容, 並且懂得我們實作的程式庫內容, 才能順利進入狀況。

取回 xawtv 的原始程式碼解開後, 在 libng/ 目錄下可以看到 grab-v4l.c 的檔案, 另外還有一個 grab-v4l2.c 的檔案, 這是 video4linux2 (version 2) 的版本。這裡我們先介紹 video4linux 的版本 -grab-v4l.c。

grab-v4l.c 的程式碼架構

大略掃瞄過 grab-v4l.c 的程式碼後, 發現 grab-v4l.c 與上一期我們實作的 video4linux 程式庫的架構很像。

其實大多數利用 video4linux 來設計應用程式的軟體, 其 video4linux 的 API 部份大多是自行重寫的, 反而很少利用現成的程式庫, 因此仔細研究別人的程式碼, 再來改進我們自己的 video4linux 程式庫是我們的最終目的。

程式一開始也是宣告了一個 ng_driver 結構的變數 (v4l_driver):

#ifndef __linux__
const struct ng_driver v4l_driver;
#else /* __linux__ */

然後可以看到 open 與 close 二個函數:

static void* v4l_open(char *device);
static int v4l_close(void *handle);

接下來還有許多函數的宣告, 同時還可以看到一些結構的宣告, 例如:

static struct STRTAB norms_v4l[] = {
{ VIDEO_MODE_PAL, "PAL" },
{ VIDEO_MODE_NTSC, "NTSC" },
{ VIDEO_MODE_SECAM, "SECAM" },
{ VIDEO_MODE_AUTO, "AUTO" },
{ -1, NULL }
};

我們可以用來顯示 channel 是 PAL/NTSC/SECAM 或是 AUTO。

xawtv 實作出來的 v4l_open() 函數可精彩了, 除了有設計函數應該要有的嚴謹的錯誤檢查外, v4l_open 也對硬體做了一些檢查。

xawtv 的 v4l 程式庫也有 v4l_close() 函數, 用來關閉已開啟的 video4linux 裝置。

在影像頁框擷取方面, 共有底下 5 個函數:

static int v4l_setformat(void *handle, struct ng_video_fmt *fmt);
static int v4l_startvideo(void *handle, int fps, int buffers);
static void v4l_stopvideo(void *handle);
static struct ng_video_buf* v4l_nextframe(void *handle);
static struct ng_video_buf* v4l_getimage(void *handle);

函數的名稱已經將其功能表達的很清楚了, 因此不再重覆解釋。另外比較特別的是, xawtv 的 video4linux 也支援了 framebuffer, 主要函數為:

int v4l_setupfb(void *handle, struct ng_video_fmt *fmt, void *base)

xawtv 的 video4linux 程式庫整體架構相當明白簡單, 程式碼也很好懂, 剩下的重點在於如何利用 video4linux 的 mmap 模式來擷取二頁的影像, xawtv 的 video4linux 程式庫的使用方式我們只要了解這一點即可。
xawtv 的 video4linux 其中對影像擷取卡做初始化的方法我們已經會了, 再來就是做影象擷取的部份。

mmap 方式我們將在下一期再做介紹。接下來的部份將瀏覽一下 xawtv 的功能架構與使用界面, 以利我們去研究 xawtv 的程式碼, 並且還會介紹一個 Linux 下的 MP3 撥放程式 --, 會介紹 xxx 的原因是因為 xxx 也用到了 streaming 的技術來撥放 MP3 檔案。

xawtv 的功能

底下我們將展示以 CCD (Composite 端子) 視訊裝置輸入影像, 並且利用 xawtv 顯示動態影象的設定方式。

xawtv 的輸出結果


圖 1

這是 xawtv 顯示動態影象的結果, 我們利用的是 CCD 視訊裝置, 視訊來源為 Composite, TV Norm 為 NTSC。

要有正確的顯示結果, 必須正確地設定 TV Norm 與 Video Source 兩個項目。

xawtv 的設定選單

在 xawtv 的主畫面按二下滑鼠右鍵後, 就會出現圖 2 的視窗。幾個常用的功能說明如下:

• Full Screen on/off: 切換是否要全螢幕顯示, 不過影像的大小則是跟視訊裝置有關。
• Grab Image: 將目前的畫面存成圖檔 (ppm 或 jpeg)。
• Record Movie (avi): 錄製 avi 的電影檔。
• Bright/Hue/Contrast/Color: 調整視訊的對比、亮度、顏色。


圖2

設定 TV Norm

點取 TV Norm 項目後, 將 TV Norm 設定在正確的參數, 筆者使用的是 NTSC 的 CCD, 因此必須將這個項目設成 NTSC。

#圖: xawtv-03.tif
圖 3

設定 Video Source

點取 Video Source 後, 再選取正確的視訊來源, 大部份的 CCD 都是 Compoiste 端子, 因此選擇 Composite1。

#圖: xawtv-04.tif
圖 4

xawtv 會列出目前影像擷取卡可用的視訊來源, 我們只要將視訊裝置接到正確的視訊來源, 並完成 TV Norm 與 Video Source 的設定後就可以正確顯示動態影像了。

利用 video4linux 來初始化影像擷取卡的方法在上一篇文章 (2) 中已列出完整範例程式碼, 並且做了詳細的說明。下一期我們將會更進一步來撰寫設定 TV Norm 與 Video Source 的程式碼。

配合介紹如何設計 TV Norm 與 Video Source 的設定程式碼, 我們還會根據 xawtv 的幾個功能並配合 video4linux 來實作 xawtv 上的功能 (frame grab), 並且會列出完整的程式碼範例做說明。

xawtv 也提供針對 FreeBSD 與 OpenBSD 的 BT848/BT878 軀動程式 (bktr) 所設計的影像擷取功能, 原始程式碼放在 xawtv 裡的 libng/ 目錄, 檔名為 grab-bsd.c 檔案。

(MP3 - streaming 部份...)

]]> https://www.jollen.org/blog/2001/07/linux_video_streaming_3.html https://www.jollen.org/blog/2001/07/linux_video_streaming_3.html GNU Toolchains & Linux Systems Programming Tue, 17 Jul 2001 06:49:00 +0800 繼上一篇介紹過 Video Streaming 的影像標準與網路通訊協定後，本期將要實際介紹目前常見的 Video Streaming 產品，並且由基本構成開始講解。本期首先介紹 video4linux 的設計方式。

Video Streaming 產品介紹

目前在網路上流行的 Video Streaming 產品相當多，這些利用 Video Streaming 技術設計的軟體在網路多媒體的應用已經有相當長的一段時間了。

底下先來介紹幾套常用的 Video Streaming 軟體。

Read Video

Real Video 是 Real Networks 公司的產品，Real Video 主要支援了 video-on-demand*1 的功能。Real Video 可以讓我們經由網站來播放串流影像 (streaming video)。

由於我們的最終目的是實作出一個可以做 video streaming 的軟體，所以在這裡我們將以 Real Video 做為標竿，並以 Linux 為基礎來設計 video streaming 的軟體。

mod_mp3

mod_mp3 是 Open Source 的 streaming 軟體。mod_mp3 並不是 Video Streaming 的軟體，但同樣是利用 streaming 的技術所設計的 apache module。

mod_mp3 可以利用 apache 來架設 streaming server，主要的功能是將 MP3 放進 cache 裡，再利用撥放程式就可以經由網路享受 MP3 streaming 的服務。

mod_mp3 的架設相當簡單，將 mod_mp3 以 DSO 方式安裝後，只要在 httpd.conf 裡加上 VirtualHost 的設定即可：

Listen 7000
<VirtualHost www.jollen.org:7000>
ServerName www.jollen.org
MP3Engine On
MP3CastName "jollen box"
MP3Genre "Much, nutty"
MP3 /home/nfs/private/mp3
MP3Random On
Timeout 600
ErrorLog /var/log/mp3_stream.log
</VirtualHost>

其中的設定項目說明如下：

• MP3 - MP3 路徑或檔名
• MP3Engine - 啟動或關閉 MP3 streaming server
• MP3CastName - server name
• MP3Genre - Genre that will be sent to the client
• MP3Playlist - 如果 MP3 Player 支援 Playlist，可以設定這個項目
• MP3Cache - cache 目錄

VIC

VIC 也是屬於 Open Source 的軟體。VIC 全名為video conferencing，故名其義，VIC 是一種視訊會議的軟體。VIC 是由加州柏克來大學的 Network Research Group 所發展。

VIC 是相當棒非常適合用來研究 Video Streaming 的 Open Source 軟體，主要是因為 VIC 幾乎包含了 Video Streaming 相關的技術。

VIC 值得我們研究的原因是因為 VIC 支援了底下所列的功能：

• IPv6
• 使用 video4linux 的捕像捕捉功能
• H261、H263 與 H263+ codec
• Software JPEG 與 BVC 編碼
• Raw YUV packetiser/codec
• RTIP/RTP 通訊協定
• the IP Multicast Backbone (MBone)
• 支援 video4linux 的 mmap

這些特色幾乎已經包括 Video Streaming 所應具備的技術了，基於這些特點，VIC 的原始程式碼相當吸引人，因此有意研究 Video Streaming 的 programmer 應該好好閱讀一下 VIC 的原始程式碼。

VideoLAN

VideoLAN 是一個可以做 MPEG 與 DVD 擴播 (broadcast) 播放的軟體，VideoLAN 分成二個部份，一個是 VLAN server，另一個則是 vlc 用戶端播放程式。

VLAN server 將 DVD 與 MPEG 影像利用 broadcast 方式擴播到區域網路上，使用者端再利用 vlc 接收封包並播放。這樣做的好處是可以減少重覆的 I/O 動作，VLAN server 將影像擴播出去後，區域網路上的用戶端再利用 vlc 接收封包並播放。

VideoLAN 支援 X11、SDL、Linux framebuffer、GGI、BeOS API、MacOS X API 播放方式，並且支援 DVD 與 AC3 (杜比音效)。

video4linux 實作

看過幾套現成的 Video Streaming 後，還是要回到本文的主題 -- Linux 如何設計 Video Streaming 的應用程式。上一期所介紹的 Video Streaming 基本觀念是進入 Video Streaming 領域相當重要而且基本的知識，像是 PASL/NTSC、RTP...等等。

RealNetworks 公司的產品裡，要建置網站的即時 (live) 影像是相當容易的。只要利用 RealNetworks 公司的產品配合影像捕捉卡 (Video Capture Card) 與 CCD 就可以達到。

從這裡可以看出，如果我們想要實作一套這樣的小系統，第一個所要面臨的問題就是如何在 Linux 下軀動影像捕捉卡，再來就是如何設計影像捕捉的程式。

在影像捕捉卡方面，Linux kernel 2.2 版本的支援已經相當完備了，很多影像捕捉卡在 Linux kernel 2.2 上都可以順利軀動並且正常工作。

而在程式設計方面，我們則是先利用 Linux kernel 所提供的 video4linux APIs 來設計程式。這一期的目的在於利用 video4linux 來實作一個供應用程式使用的程式庫 (library)。

影像捕捉卡

先來檢視一下 Osprey 100 這張影像捕捉卡。Osprey 100 是 Real Networks 公司所推薦配合他們產品的一張影像捕捉卡，配合 Osprey 100 與 RealNetworks 的產品我們可以利用 broadcast 或 on-demand 做到實況轉播 (live) 的功能。

Osprey 100 在硬體功能上可以支援到每秒 30 個畫面 (fps -- frame per second)，並且支援 NTSC 與 PAL 輸入。

不過在實作上，筆者並不使用 Osprey 100。筆者使用的影像捕捉卡是 ，這張卡算是比較「俗」一點的卡，但是也有好處，因為在 Linux 上很容易安裝。

在繼續往下發展我們的系統前，必須先安裝好影像捕捉卡與軀動程式，這部份不在這篇文章的範圍，所以請您參考相關的文章來安裝軀動程式。

以筆者這張卡為例，使用的是 Brooktree Corporation 的卡，所以只要安裝 bttv 模組即可，同時，bttv 模組在 Linux kernel 2.2.17 下也會用到 i2c-old 與 videodev 兩個模組，所以也要一併安裝。在命令列下，安裝這三個模組的命令為：

linux# insmod i2c-old
linux# insmod videodev
linux# insmod bttv

當然要確定 Linux kernel 有編譯這三個模組的支援，然後再把這三個模組加到 /etc/modules.conf (Red Hat 7.0) 裡。

不同版本的 kernel 所要安裝的模組不一定相同！還請注意，例如 i2c 相關模組就是如此。

video4linux 使用的設備檔

Linux 下與 video4linux 相關的設備檔與其用途：

/dev/video	Video Capture Interface
/dev/radio	AM/FM Radio Devices
/dev/vtx	Teletext Interface Chips
/dev/vbi	Raw VBI Data (Intercast/teletext)

video4linux 除了提供 programmer 與影像捕捉有關的 API 外，也支援其它像是收音機裝置。

接下來介紹 video4linux 設計方式，所使用的 Linux kernel 版本為 2.2.16。這篇文章將簡單介紹實作 video4linux 的方法，所以請準備好 Linux kernel 原始碼下的 Documentation/v4l/API.html 文件並了解 What's video4linux。

_v4l_struct -- 定義資料結構

首先，先定義會用到的資料結構如下：

#ifndef _V4L_H_
#define _V4L_H_

實作 video4linux 時，必須 include 底下二個檔案：

#include <sys/types.h>
#include <linux/videodev.h>

接下來是 PAL、CIF、NTSC 規格的畫面大小定義：

#define PAL_WIDTH 768
#define PAL_HEIGHT 576
#define CIF_WIDTH 352
#define CIF_HEIGHT 288
#define NTSC_WIDTH 640
#define NTSC_HEIGHT 480

接下來我們的重點是 _v4l_struct structure，這個 structure 包含了在 API.html 提到，將會使用到的 data structure，底下將完整地定義 _v4l_struct，但在實作時並不會全部用到。

_v4l_struct 定義如下：

struct _v4l_struct
{
int fd;
struct video_capability capability;
struct video_buffer buffer;
struct video_window window;
struct video_channel channel[8];
struct video_picture picture;
struct video_tuner tuner;
struct video_audio audio[8];
struct video_mmap mmap;
struct video_mbuf mbuf;
unsigned char *map;
};

為了設計方便，我們再做底下的定義：

typedef struct _v4l_struct v4l_device;

以後宣告 struct _v4l_struct 時，將一律使用 v4l_device。

實作函數宣告

底下宣告將要實作的 functions，我們採取 top-down 的實作方式，也就是先將所有會用到的函數事先規劃，並宣告在原始碼裡。當然，本文並不會介紹底下所有的函數，但重要的函數則會做說明。

實際做設計時，有些函數可能會在後期才會被設計出來。我們所要實作的函數與函數宣告如下：

extern int v4l_open(char *, v4l_device *);
extern int v4l_close(v4l_device *);
extern int v4l_get_capability(v4l_device *);
extern int v4l_set_norm(v4l_device *, int);
extern int v4l_get_channels(v4l_device *);
extern int v4l_get_audios(v4l_device *);
extern int v4l_get_picture(v4l_device *);
extern int v4l_grab_init(v4l_device *, int, int);
extern int v4l_grab_frame(v4l_device *, int);
extern int v4l_grab_sync(v4l_device *);
extern int v4l_mmap_init(v4l_device *);
extern int v4l_get_mbuf(v4l_device *);
extern int v4l_get_picture(v4l_device *);
extern int v4l_grab_picture(v4l_device *, unsigned int);
extern int v4l_set_buffer(v4l_device *);
extern int v4l_get_buffer(v4l_device *);
extern int v4l_switch_channel(v4l_device *, int);

v4l_open() -- 開啟 device file

首先，v4l_open() 是我們第一個應該要撰寫的函數。v4l_open() 用來開啟影像來源的設備檔。

依據 v4l_open() 的宣告，在應用程式裡，我們會這樣呼叫 v4l_open()：

v4l_device vd;

if (v4l_open("/dev/video0", &vd)) {
return -1;
}

在應用程式裡，我們宣告了一個 vd 變數 (v4l_device 型態)，再呼叫 v4l_open() 將設備檔開啟。

如果可以開啟 "/dev/video0" 則將取回的資訊放到 vd 裡，vd 是 v4l_device 也就是之前宣告的 _v4l_struct。

接下來，讓我們來看看 v4l_open() 要如何實作：

#define DEFAULT_DEVICE "/dev/video0"

int v4l_open(char *dev, v4l_device *vd)
{
if (!dev)
dev = DEFAULT_DEVICE;

if ((vd->fd = open(dev, O_RDWR)) < 0) {
perror("v4l_open:");
return -1;
}

if (v4l_get_capability(vd))
return -1;

if (v4l_get_picture(vd))
return -1;

return 0;
}

為了設計出完整的 video4linux 程式庫，一開始我們就定義了 DEFAULT_DEVICE，當應用程式輸入的 dev 設備檔參數不存在時，就使用預設的設備檔名稱。程式片段如下：

if (!dev)
dev = DEFAULT_DEVICE;

與一般 Linux Programming 一樣，我們使用 open() 將 device file 打開：

if ((vd->fd = open(dev, O_RDWR)) < 0) {
perror("v4l_open:");
return -1;
}

如果您不熟悉 Linux 下 open() 的使用方法，請參考 Linux programming 相關資料。熟悉 UNIX programming 的讀者一定知道，open() 也與 STREAMS 的觀念相關，這部份在後面會再另外做介紹。

將設備檔開啟後，把傳回來的 file description 放到 vd->fd 裡。

成功開啟設備檔後，根據 API.html 的說法，我們要先取得設備的資訊與影像視窗的資訊，所以這裡再實作 v4l_get_capability() 與 v4l_get_picture() 來完成這二件工作。

v4l_get_capability() 會利用 ioctl() 取得設備檔的相關資訊，並且將取得的資訊放到 struct video_capability 結構裡。同理，v4l_get_picture() 也會呼叫 ioctl() ，並將影像視窗資訊放到 struct video_picture 結構。

v4l_get_capability() 函數程式碼如下：

int v4l_get_capability(v4l_device *vd)
{
if (ioctl(vd->fd, VIDIOCGCAP, &(vd->capability)) < 0) {
perror("v4l_get_capability:");
return -1;
}
return 0;
}

在這裡，其實只有底下這一行才是 v4l_get_capability 的主力：

ioctl(vd->fd, VIDIOCGCAP, &(vd->capability));

其它部份都是屬於錯誤處理的程式碼，在本文，筆者都將函數寫的完整一點，即包含了錯誤檢查，因為我們想要實作一個 v4l 的 library。

vd->fd 是由 v4l_open 傳回來的 file descriptor，而傳遞 VIDIOCGCAP 給 ioctl() 則會傳回設備相關資訊，在這裡則是存放於 vd->capability。

v4l_get_ picture() -- picture 的初始化

取得設備資訊後，我們還要再取得影像資訊，所謂的影像資訊指的是輸入到影像捕捉卡的影像格式。

在 _v4l_struct 結構裡，我們宣告 channel 如下：

struct video_picture picture;

初始化 picture 的意思就是要取得輸入到影像捕捉卡的影像資訊，我們設計 v4l_get_ picture() 函數來完成這件工作。

v4l_get_ picture () 完整程式碼如下：

int v4l_get_picture(v4l_device *vd)
{
if (ioctl(vd->fd, VIDIOCGPICT, &(vd->picture)) < 0) {
perror("v4l_get_picture:");
return -1;
}
return 0;
}

傳遞VIDIOCGPICT 給 ioctl() 則會傳回影像的屬性 (image properties)，這裡則是將影像屬性存放於 vd-> picture。

v4l_get_channels() -- channel 的初始化

接下來，我們還要再做 channel 的初始化工作。還記得在 _v4l_struct 結構裡，我們宣告 channel 如下：

struct video_channel channel[8];

channel 是一個 8 個元素的陣列，一般絕大部份都會宣告 4 個元素，因為大部份的影像捕捉卡都只有 4 個 channel。幾乎沒有影像捕捉卡有 8 個 channel的。

初始化 channel 的意思就是要取得「每個」 channel 的資訊，我們設計 v4l_get_channels() 函數來完成這件工作。

v4l_get_channels() 完整程式碼如下：

int v4l_get_channels(v4l_device *vd)
{
int i;

for (i = 0; i < vd->capability.channels; i++) {
vd->channel[i].channel = i;

if (ioctl(vd->fd, VIDIOCGCHAN, &(vd->channel[i])) < 0) {
perror("v4l_get_channel:");
return -1;
}
}
return 0;
}

要記得，我們是對每個 channel 做初始化，所以必須用一個迴圈來處理每個 channel。那我們怎麼知道影像捕捉卡上有幾個 channel 呢？記得我們設計 v4l_open() 時也「順路」呼叫了 v4l_get_capability() 嗎！v4l_get_capability() 所取得的設備資訊，就包含了影像捕捉卡的 channel 數。這個資訊儲存於 vd->capability.channels 裡。

由於 v4l_get_capability() 是必備的程序，所以我們就順便寫在 v4l_open() 裡。當然，如果您沒有在 v4l_open() 裡呼叫 v4l_get_capability()，這樣的設計方式當然沒有錯，只是在設計應用程式時，要記得在 v4l_open() 後還要再呼叫 v4l_capability() 才行。

在迴圈裡，首先先替每個 channel 做編號：

vd->channel[i].channel = i

然後再取得 channel 的資訊：

ioctl(vd->fd, VIDIOCGCHAN, &(vd->channel[i]);

傳遞 VIDIOCGCHAN 給 ioctl() 則會傳回 channel 的資 訊，這裡則是將 channel 的資訊存放於 vd-> channel[i]。

要注意一下，在 kernel 2.4 的 API.html 文件裡，粗心的 programmer 將 VIDIOCGCHAN 打成 VDIOCGCHAN，少了一個 "I"。

v4l_get_audios() -- audio 的初始化

接下來，我們再做 audio 的初始化工作，audio 的初始化方式與初始化 channel 的方法很像。在 _v4l_struct 結構裡，我們宣告 auduio 的結構如下：

struct video_audio audio[8];

audio 是一個 8 個元素的陣列，與 channel 一樣。一般絕大部份都會宣告 4 個元素，因為大部份的影像捕捉卡都只有 4 個 audio。幾乎沒有影像捕捉卡有 8 個audio的。

初始化 audio 的意思就是要取得「每個」 audio 的資訊，我們設計 v4l_get_audios() 函數來完成這件工作。

v4l_get_audios() 完整程式碼如下：

int v4l_get_audios(v4l_device *vd)
{
int i;

for (i = 0; i < vd->capability.audios; i++) {
vd->audio[i].audio = i;

if (ioctl(vd->fd, VIDIOCGAUDIO, &(vd->audio[i])) < 0) {
perror("v4l_get_audio:");
return -1;
}
}
return 0;
}

別忘了，我們仍然要對每個 audio 做初始化，所以必須用一個迴圈來處理每個 audio。那我們怎麼知道影像捕捉卡上有幾個 audio 呢？與取得 channel 的方式一樣，audio 數量的資訊儲存於 vd->capability. audios 裡。

在v4l_get_audios() 的迴圈裡，首先先替每個 audio 做編號：

vd->audio[i].audio = i;

然後再取得 audio 的資訊：

ioctl(vd->fd, VIDIOCGAUDIO, &(vd->audio[i]);

傳遞 VIDIOCGAUDIO 給 ioctl() 則會傳回 audio 的資訊，這裡則是將 audio 的資訊存放於 vd-> audio[i]。

中標=v4l_close() -- 關閉裝置檔

v4l_close() 程式相當簡單，所以不用再多做介紹啦！直接列出程式碼如下：

int v4l_close(v4l_device *vd)
{
close(vd->fd);
return 0;
}

配合應用程式來設計

設計了幾個函式後，接下來我們要實地設計一個應用程式來說明如何使用 v4l_xxx() 系列的函式。

底下是一個在應用程式裡初始化影像捕捉卡，並且列出取得的資訊的程式範例 (完整程式碼)：

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include "v4l/v4l.h"

v4l_device vd;

int device_init(char *dev)
{
if (dev == NULL) {
dev = "/dev/video0"; //set to default device
}

if (v4l_open(dev, &vd)) return -1;
if (v4l_get_channels(&vd)) return -1;

printf("%s: initialization OK... %s\n"
"%d channels\n"
"%d audios\n\n",
dev, vd.capability.name, vd.capability.channels,
vd.capability.audios);

v4l_close(&vd);
return 0;
}

int main()
{
if (device_init("/dev/video0") == -1) {
perror("device_init: failed...");
exit(1);
} else {
printf("OK!\n");
}
exit(0);
}

我們將這個程式存成 main.c，整個程式不用再多做介紹了吧！程式裡用到的地方都有介紹過，其中 vd.capability.name 代表界面的 canonical name。

device_init() 最後呼叫 v4l_close() 將裝置檔關閉，別忘了這個重要的工作！

v4l/v4l.h 的內容如下 (完整程式碼)：

#ifndef _V4L_H_
#define _V4L_H_

#include <sys/types.h>
#include <linux/videodev.h>

#define PAL_WIDTH 768
#define PAL_HEIGHT 576
#define CIF_WIDTH 352
#define CIF_HEIGHT 288
#define NTSC_WIDTH 640
#define NTSC_HEIGHT 480

struct _v4l_struct
{
int fd;
struct video_capability capability;
struct video_buffer buffer;
struct video_window window;
struct video_channel channel[8];
struct video_picture picture;
struct video_tuner tuner;
struct video_audio audio[8];
struct video_mmap mmap;
struct video_mbuf mbuf;
unsigned char *map;
};

typedef struct _v4l_struct v4l_device;

extern int v4l_open(char *, v4l_device *);
extern int v4l_close(v4l_device *);
extern int v4l_get_capability(v4l_device *);
extern int v4l_set_norm(v4l_device *, int);
extern int v4l_get_channels(v4l_device *);
extern int v4l_get_audios(v4l_device *);
extern int v4l_get_picture(v4l_device *);
extern int v4l_grab_init(v4l_device *, int, int);
extern int v4l_grab_frame(v4l_device *, int);
extern int v4l_grab_sync(v4l_device *);
extern int v4l_mmap_init(v4l_device *);
extern int v4l_get_mbuf(v4l_device *);
extern int v4l_get_picture(v4l_device *);
extern int v4l_grab_picture(v4l_device *, unsigned int);
extern int v4l_set_buffer(v4l_device *);
extern int v4l_get_buffer(v4l_device *);
extern int v4l_switch_channel(v4l_device *, int);

#endif

為了維護方便，這裡我們建立一個 v4l/ 的目錄來放 v4l.h 與底下的 v4l.c 檔案。

編譯 main.c 時，也別了也要編譯 v4l.c，並且要指定 v4l.o 的位置給 main.o 才能順利 link；或者我們可以把 v4l.o 再做成 libv4l.a 形式，這是屬於 Linux programming 相關的主題，請自行參考這方面的資料。

我們的 v4l_xxx() 函數則是放在 v4l/v4l.c 檔案裡。v4l/v4l.c 的內容如下 (完整程式碼，只列出目前會用到的函數)：

#include <stdio.h>
#include <unistd.h>
#include <error.h>
#include <assert.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/mman.h>
#include <linux/videodev.h>
#include "v4l.h"

#define DEFAULT_DEVICE "/dev/video0"

int v4l_open(char *dev, v4l_device *vd)
{
if (!dev)
dev = DEFAULT_DEVICE;

if ((vd->fd = open(dev, O_RDWR)) < 0) {
perror("v4l_open:");
return -1;
}

if (v4l_get_capability(vd))
return -1;

if (v4l_get_picture(vd))
return -1;

return 0;
}

int v4l_get_capability(v4l_device *vd)
{
if (ioctl(vd->fd, VIDIOCGCAP, &(vd->capability)) < 0) {
perror("v4l_get_capability:");
return -1;
}
return 0;
}

int v4l_get_channels(v4l_device *vd)
{
int i;

for (i = 0; i < vd->capability.channels; i++) {
vd->channel[i].channel = i;

if (ioctl(vd->fd, VIDIOCGCHAN, &(vd->channel[i])) < 0) {
perror("v4l_get_channel:");
return -1;
}
}
return 0;
}

int v4l_get_audios(v4l_device *vd)
{
int i;

for (i = 0; i < vd->capability.audios; i++) {
vd->audio[i].audio = i;

if (ioctl(vd->fd, VIDIOCGAUDIO, &(vd->audio[i])) < 0) {
perror("v4l_get_audio:");
return -1;
}
}
return 0;
}

int v4l_get_picture(v4l_device *vd)
{
if (ioctl(vd->fd, VIDIOCGPICT, &(vd->picture)) < 0) {
perror("v4l_get_picture:");
return -1;
}
return 0;
}

int v4l_close(v4l_device *vd)
{
close(vd->fd);
return 0;
}

當程程式無法初始化裝置時，會出現的錯誤訊息：

v4l_open:: No such device
device_init: failed...: No such device

如果出現這樣的錯誤：

v4l_open:: Device or resource busy
device_init: failed...: Device or resource busy

最大可能的原因可能是：(1 )軀動程式沒有安裝好或軀動程式不適用，(2)「前人」的程式忘了將裝置檔關閉。

如果程式可以順利初始化裝置，就會看到這樣的訊息：

/dev/video0: initialization OK... BT878(Hauppauge new)
3 channels
1 audios

OK!

我們將取得的裝置資訊 print 到螢幕上，以了解取得的相關資訊。在下一期的文章裡，我們將會介紹更多 video4linux 的設計方法，來做到更進階的工作。

在這裡我們看到程式已經成功初始代我們的裝置，並且知道裝置有 3 個 channel、1 個 audio。

STREAMS Programming

接下來要介紹的是屬於觀念性的話題，比較不重要。我們將以理論為主，來講解 "STREAMS" 程式設計的基礎觀念。

什麼是 STREAMS?

在 Solaris 2 的 kernel 裡，STREAMS 定義了一個標準界面，這個界面主要的功能是提供裝置與 kernel 之間的 I/O 溝通管道。這個界面其實是由系統呼叫 (system calls) 與核心常式 (kernel routines) 所組成，我們可以簡單表示成下圖：



圖 1

圖中的 Module 標示為 Optional，也就是在 Stream Head 與 Driver 之間，並不一定存在這個 Module，這個 Module 屬於中間者的角色，也就是，當 stream (解釋成資料串流或許比較好理解) 在 Stream Head 與 Driver 之間「流」動時，Module 會從中做額外的處理。

有時這個 Module 是相當重要的，因為資料串流必須經過特殊的處理，才能流向彼方。

這種 kernel 設計的方式相當好，因為 Module 一定是動態 (dynamic) 被裝到串流裡的。而且，這個 Module 是由 user process 所載入，因此，user 可以根據不同的心情「抽換」不同的 Module。

在最底下 Driver 的地方一般指的是 UNIX 底下的設備檔，到這裡，讀者有沒有感覺到，是不是有些觀念跟我們實作出來 video4linux 程式庫可以相連呢！

由圖可以看出，根據 stream 的流向，可以將 stream 分成 downstream 與 upstream。由於 stream 是雙向的，所以我們可以把 STREAMS 稱為全雙工模式 (full-duplex) 的資料處理與傳送。

我們可以把圖 1 再簡單表示成下圖：



圖 2

由這裡可以發現一個事實，整個 STREAMS 的起點是 Driver，而終點是 User Process。在 user space 與 kernel space 之間則是由 Stream head 來連接。

當然，user process 可能是 local user process 或者 remote user process。目前為止，我們尚未進入 user process 的部份，所以暫時不會提到 RTP 等通訊協定的設計。

接下來，再介紹一下 downstream 與 upstream。通常，downstream 也稱為 write side，也就是寫入資料那一方；而 upstream 則稱為 read side，也就是讀取資料那一方。那麼，在 UNIX programming 裡，什麼時候會牽涉到 STREAMS 呢？

最簡單的例子莫過於由終端機讀取字元的範例了。一個簡單的程式片段如下：

main()
{
char buf[1024];
int fd;
int count;

if ((fd = open("/dev/tty1", )_RDWR)) < 0) {
perror("open: /dev/tty1");
exit(1);
}

while ((count = read(fd, buf, sizeof(buf))) > 0) {
if (write(fd, buf, count) != count) {
perror("write: /dev/tty1");
break;
}
}

exit(0);
}

對 Network programming 而言，如果我們要經由 Socket 讀取字元，可以寫一個簡單的程式如下：

int main(int argc, char *argv[])
{
char *buff = "Hello, socket!";
int sockfd;
struct sockaddr_in serv_addr;

sockfd = socket(AF_INET, SOCK_STREAM, 0);

serv_addr.sin_family = AF_INET;
serv_addr.sin_addr.s_addr = inet_addr("192.168.1.10"); // ip
serv_addr.sin_port = htons(3999); // port

connect(sockfd, &serv_addr, sizeof(serv_addr));
write(fd, buff, strlen(buff));

close(sockfd);
exit(0);
}

這是一個 client 端向 server 送出字元的程式範例，這段程式主要是要讓讀者看出，經由終端機設備寫入字元時，是利用 write() 函數，而在 socket 上寫入字元，卻也是利用 write() 函數。

這種 UNIX kernel 整合週邊設備與網路 I/O 的機制事實上就是 STREAMS programming 所要解決的問題。整合 UNIX kernel 與網路 I/O 的工作首先由Dennis Ritchie 這位大師所進行，所以現在我們才會擁有現今這麼強大的 UNIX 系統。

到目前為止，我們仍然只對 video capture card 做初始化的動作，並討論一些觀念，接下來的文章將以循序漸進的方式實作整個 Video Streaming 系統。

下期預告

下一期我們將實作更進階的 video4linux，並且討論一下 i2c 與 bttv 這兩個 driver，同時也介紹一些較實用且有趣的相關主題。

*1: 見 PC2000/4月份：Linux 的應用--Video Streaming(一)

網路資源&參考資料：

• VideoLAN -- http://www.videolan.org/
• VIC -- http://www-nrg.ee.lbl.gov/vic/
• -- http://www-mice.cs.ucl.ac.uk/multimedia/software/vic/
• mod_mp3 -- http://media.tangent.org/
• Linux kernel 文件 -- video4linux
• Real Networks -- http://www.realnetworks.com/
• Solaris 2.5 -- STREAMS programming
• BTTV -- http://www.metzlerbros.de/bttv.html
]]> https://www.jollen.org/blog/2001/05/linux_video_streaming_2.html https://www.jollen.org/blog/2001/05/linux_video_streaming_2.html GNU Toolchains & Linux Systems Programming Mon, 14 May 2001 14:36:00 +0800 Video Streaming 來的正是時候

看到 "Video" Streaming 就知道這個技術與影音有關。Video Streaming 是一種經由網路來撥放影音檔案的技術，Video "Streaming" 的基本概念為「一邊下載一邊撥放」，我們稱之為「Play as received」。

經由 Internet 如果要收看遠端伺服器的電視檔案，最原始的做為是「下載後再撥放」，也就是經由 FTP 或 HTTP 將整個檔案下載至本地端後再利用撥放程式來撥放，我們稱之為「Play after download」。

以最常見的例子來講，我們可以經由網路將 MP3 完整下載後再撥放，也就是 Play after download，或者我們也可以一邊下載 MP3 一邊聽音樂，這種方式則稱為 Play as received。其他的應用範例還很多，例如利用 RealPlayer「即時觀看影片或是聽音樂」，這種即時撥放的方式即是 Play as received，我們稱這樣的技術為 Video Streaming Technology。

為什麼說 Video Streaming 的技術來的正是時候呢？舉個最簡單的情況，你可能在下載 MP3 之前想要試聽一下音樂的內容，而下載音樂片段的方式又顯得不夠友善，這時如果利用 Video Streaming 的技術來讓網友視聽，不但方便，而且不必浪費時間來下載不喜歡的音樂的。

隨著網路頻寬的改進與 IPv6 的出現，Video Streaming 的應用將越來越廣泛，利用 Video Streaming 來設計的資訊家電也會越來越多，例如較常被提及的網路電話 (InterPhone)。

除了寬頻網路的普及外，儲存設備的大進步也是加速 Video Streaming 進用普及的最大動力，例如利用 Linux 設計的 NAS 可以被用來當做大型的影音伺服器或是動態電影資料庫 (DMD)。

VCD & MPEG-1

要提到撥放動態影音的先軀，絕對要先從 VCD 說起，因為這是在電腦出現後，最能深入消費者市場的產品。

想當年，要撥放 VCD 除了要有一台當時算是高擋貨的 1x CD-ROM 外，還要再另外加裝也是高擋貨的 MPEG 卡。撥放 VCD 其實就是 Video Streaming 的技術，因為 VCD 的資料是一邊讀取一邊撥放，那為什麼要有 MPEG Card 呢？理所當然的，這是因為MPEG-1 的標準。

MPEG-1 被設計在 1x CD-ROM 上撥放 VCD，而 VCD 上的資料必須經由 MPEG Card 解碼 (decode) 後才能撥放。但是隨著硬體的進步，現在可以經由軟體來做 MPEG-1 解碼的工作。我們將在後文介紹 MPEG-1 的設計概念。

DVD & MPEG-2

MPEG-2 常被提到則是由於 DVD 的流行。不管是 MPEG-1 或是 MPEG-2，其實是一種編碼的技術，而 DVD-ROM 則是選擇了 MPEG-2 來當做它的壓縮標準。

而 DVD 之所以無法像 VCD 一樣能被「備份到硬碟」，則是由於其中又加進了三道的保護，第二道保護就是玩家們耳熟能詳的 CSS。在 Linux 下之所以無法有「合法」的 DVD Player，就是受制於 CSS 的關係。

利用 NAS 來設計 Video Server，要儲存並廣撥 VCD 已經沒有技術上的障礙，但是要儲存並擴撥 DVD，則有法律上的問題，這點是值得我們深思的一個問題。因為目前 CSS 的技術掌握在日本人手裏，要取得這項技術必須簽署 NDA，不過 CSS 並非不可破解想必大家都知道，但是就是有版權上的問題。

影像編碼技術介紹

目前學術界已經發展出許多處理影像訊號壓縮及編碼的技術 (codecs)，談到這些技術，應用最廣泛的編碼標準底下四種：

1. ) H.261
2. ) H.263
3. ) JPEG, MJPEG
4. ) MPEG

底下將分別簡單介紹這四種編碼技術。

H.261 標準

H.261 的影像編碼標準出現在 1990 年的 ITU。一開始的用途主要是支援影像電話 (video phone) 與視訊會議 (video conferencing)。H.261 的格式有二種，分別有不同的解析度：

1. ) QCIF：176x144
2. ) CIF：352x288

H.261 的 fps (frames per second) 可以達到 7.5, 10, 15 與 30 fps。由於 H.261 一開始是架構在 ISDN B 上面，而 ISDN B 的傳輸速度為 64 Kbps，所以 H.261 也被稱為 Px64 (x = 1 to 30)。

CIF 全名為 (Common Intermediate Format)，主要是為了要支援各種不同解析度的電影而被定義出來，例如 NTSC, PAL, SECAM 電視系統。而 QCIF 則是 Quarter-CIF 也就是 CIF 解析度的一半。

除此之外，H.261 也可以說是 MPEG-1 標準的前輩。

H.263 標準

H.263 是 H.261 的加強版，誕生於 1994 年 (ITU)。H.263 開始支援 PSTN，不過要特別說明一點，H.263 比 MPEG-1 還要晚出現，而且 H.263 還是基於 MPEG-1 而發展。

H.263 的標準共支援五種不同的解析度，分別為：

1. ) Sub-QCIF：128x96
2. ) QCIF：176x144
3. ) CIF：352x288
4. ) 4CIF：704x576
5. ) 16CIF：1408x1152

傳輸速度為 8 Kbps ~ 1.5 Mbps。除此之外，H.263 也是 MPEG-4 標準的基礎。

JPEG

提到 JPEG 的標準，大家可就不莫生了，由其是在 GIF 發出禁令後，JPEG 更是被廣泛應用。JPEG 的全名大家一定不莫生，他可是赫赫有名的一群技術團隊的縮寫 - Joint Photographic Experts Group。

JPEG 是 24-bit 的 "true-color" 影像標準，JPEG 的工作是將 RGB 格式的影像轉換成 YCrCB 格式，目的是為了減少檔案大小，一般約可減少 1/3 ~ 1/2 左右。

不過 MJPEG 才是我們的主角，MJPEG 全名為 "Motion" JPEG，也就是會動的 JPEG 圖檔。許多 Video Streaming 的場合，像是簡單的視訊會議軟體都會使用 MJPEG 來取代 MPEG，原因無它，因為 MJPEG 格式簡單，但缺點是不支援聲音。

MPEG-1 標準

MPEG 的標準由 ISO (International Standards Organization) 所制定，全名為 Moving Pictures Experts Group (MPEG 為 ISO 工作)，這些團隊制定了包括 MPEG-1、MPEG-2、MPEG-4 等標準。

MPEG-1 的標準比 H.263 早出現，MPEG-1 制定於 1992 年，主要用途為：視訊會議、影像電話、電腦遊戲與支援第一代的 CD-ROM。MPEG-1 被設計來支援大部份的影像與 CD-ROM 的音效，傳輸速度為 1.5 Mbps (30 fps)。

除此之外，MPEG-1 也支援 playback，例如快轉、倒帶或是跳躍，這也是 MPEG-1 好用的地方。稍後我們會簡單介紹一下 MPEG-1 的原因，以明白 MPEG-1 如何做到這些功能。

MPEG-2 標準

MPEG-2 的標準出現於 1994 年，MPEG-2 相容於 MPEG-1。MPEG-2 的出現並不是為了要取代 MPEG-1 的舊標準，而是要加強 MPEG-1 不足的地方。因此 MPEG-2 更能昇任其它工作環境，例如 HDTV、視訊廣播。

同時，MPEG-2 的解析度也支援到 HDTV 1280x720。在音效方面，MPEG-2 也支援到 6 個頻道 (MPEG-1 只支援 2 個頻道)。MPEG-2 的傳輸速度也提昇至 2Mbps ~ 10 Mbps，因此需要 4x 的 CD-ROM，但也因此 4x CD-ROM 只能儲存 18 分種的影像，所以我們利用 DVD-ROM 來儲存 MPEG-2 格式的影像，而且 DVD-ROM 也支援 Dolby 音效。

MPEG-4 標準

MPEG-4 的標準在 1993 年被提出，主要的應用用途比較廣，包括：視訊會議、影音郵件、無線裝置等等，支援的傳輸速度為 8Kbps ~ 35Mbps。

MPEG-4 可以傳送影像的物件，而不是只有影像的 "frame"，例如一連串的動作指令。因此，MPEG-1 與 MPEG-2 皆是 "frame-based" 的標準，而 MPEG-4 則是 "object-based" 的標準，未來在網路與多媒體的應會也會更普遍。

MPEG-4 目前在 Linux 上已經有 OpenMPEG 的專案計畫，發起本計畫的目地在希望可以在 Linux 上發展完整的 MPEG-4 支援環境。

Video Streaming 的網路技術

要建置一個完整的 Video Streaming 環境，在整體來看，要準備的硬體包括：伺服器、CCD、影像補捉卡等等，而在底層的技術面方面，除了前面提到的影像編碼技術外，也要配合通訊協定才能實作出 Video Streaming 的應用程式。

Video Streaming 的方式

Video 在做 Streaming 時，有三種方式可以應用：broadcasting、unicasting、multicasting。

broadcasting 的方式比較單純，他是在 LAN 上直接將一個個的影像封包丟到網路上 (server 端)，再由 client 的應用程式自網路上取回封包播放。但網路硬體層上，仍有許多需要考慮的問題，例如在 Shared Non-Switched Enthernet 上時，就會發生一些小問題。

unicasting 與 multicasting 都是屬於 IP 的傳輸方式。unicasting 採取 1 對 1 的方向傳影像給遠端，稱為 Video-on-Demand (VoD)，multicasting 則是 1 對多的傳輸方式，稱為 Near-Video-on-Demand (NVoD)。未來 IPv6 將支援 IP Multicasting，因此 Video Streaming 的應用將更為廣泛。

IPv6

IPv6 全名為 IP version 6，未來將取代目前所使用的 IPv4。IPv6 新增許多對多媒體傳輸的支援，例如 multicasting、authentication/encryption等。不過目前尚仍未全面升級，所以應用仍受限。

UDP 通訊協定

UDP 全名是 Universal Datagram Protocol，UDP 通訊協定是 Video Streaming 的基石。UDP 與 TCP 不同的是，UDP 並沒有錯誤檢查，不過這在 Video Streaming 的應用是影嚮不太的。

RTP 通訊協定

RTP 全名為 Real-Time Protocol，RTP 是在 UDP 封包之前多加 10 bytes 的檔頭，裡面記載有時間、序號、壓縮型態等資訊。RTP 是目前大多數 Video Streaming 軟體所使用的通訊協定。

RTP 可用來針對各種不同的多媒體格式做 Streaming 的工作，因為我們將影像分解成數個 RTP 封包再傳送出去，因此會遇到許多網路技術常會遇到的問題。例如，因為封包送達的時間不一，造成播放時會畫面不流暢的現像，因此，在播發時就必須使用一個緩衝區 (playout buffer) 來暫時存放並處理網路上接受到的封包。

由網路上接收的影像封包因為彼此之間到達的時間間隔不同 (Synchronous Data Packets)，所以必須利用緩衝區將這些封包做緩衝，讓彼此之間的時間間隔一樣 (Isochronous Data Packets)。

MPEG-1 的原理

MPEG-1 的編碼原理大家都應該要認識一下。MPEG-1 將影像分成一個 Group，即 GOP (Group of Pictures)，每個 GOP 有一個 Entry Point，稱為 I-frame，每個 I-frame 的大小為 15KB，另外還有 P-frame 與 B-frame。

I-frame 稱為 Independent-frame，為每個 GOP 的起點，緊接著的是二個 B-frame，B-frame 稱為 Bi-directional frame，每個 B-frame 大小為 3KB，每二個 B-frame 之間再插入一個 P-frame，即 Predictive-frame，每個 B-frame 的大小為 8KB。

GOP 共有三種不同的 frame，每種 frame 存放的影像與性質皆不同，這在以後我們實做程式時會再做更清楚的介紹。例如，我們要將影片快轉時，可以忽略掉所有的 B-frame 與 P-frame，只撥放 I-frame，如此一來便可以節省許多貴寶的網路頻寬與時間，但前提是，I-frame 必須存放主要的影像資料，事實上也是如此。

本期結語

本篇文章主要的目的是要讓大家對影像的一些標準與 Video Streaming 所使用的通訊協定有一定的認識，更多與影像有關的內容也會陸續為大家做介紹。

下一期我們要介紹更多有趣的主題，包括 Linux 核心裡的 video4linux，與 Linux 環境下的影像專案與好用的 Video Streaming 應用程式。

]]> https://www.jollen.org/blog/2001/02/linux_video_streaming_1.html https://www.jollen.org/blog/2001/02/linux_video_streaming_1.html GNU Toolchains & Linux Systems Programming Tue, 13 Feb 2001 03:41:00 +0800