前陣子接受 DigiTimes 的「手持行動裝置開發關鍵軟體技術發展」研討會邀請，當時就在思考要以什麼主題為主。一些題目大概都是老生常談了，而且又不想以介紹性的方式進行。想了又想，發現最近最當紅的主題非 WiMAX 莫屬，WiMAX 也是今年 Computex 展的主題，因此決定以 Intel 的 [Linux WiMAX development project] 專案做為討論標的。5 月 29 日這一天的演講就以「Linux WiMAX Driver 實作現況分析」定題了。

linuxmax.org 是 Intel 所支持的一個專案計畫，此計畫目前已釋出第一個 WiMAX device driver 以及 WiMAX stack。目前在 linuxwimax.org 上已能找到 Intel WiMAX Connection 2400m 的驅動程式，以及一個 WiMAX stack 驅動程式（subsystem）。2400m 是一個符合 mobile WiMAX 標準的 WiMAX chipset，mobile WiMAX 是行動 WiMAX 的一個標準（802.16e），主要給行動裝置使用。

當天的演講投影片可由此下載 [introduction_wimax_driver.pdf]。雖然定題為「Linux WiMAX Driver 實作現況分析」，不過若以 device driver 的角度來看，其實會變得比較像是在講 USB 與 network device 的 subsystem。若是以整個架構來看，WiMAX driver 在分層設計這裡已經有很不錯的實作，包含以下二個部份：

1. 透過 netlink layer 做為 user-to-kernel 的介面，在 application 端也有 API 的實作，可透過 libnl 來操作 WiMAX 的設定。
2. 針對 device driver 提供分層架構設計：struct wimax_dev 以及 wimax_dev_add()。

另外，為了解 WiMAX driver 與 kernel-space 的緊密性關性，我們透過了 2400m 的驅動程式來分析其架構關係，以及 I/O 處理方法。初步了解，WiMAX device driver 仍是透過 transport layer 來做處理，WiMAX stack 目前只提供 netlink layer 給下層的裝置驅動程式。其餘部份大略整理於投影片中，請指教。

過去大家經常在討論「Android 不是 100% 開放源碼」，但 Google 目前已做了正式的解釋，Google 表示「the core Android platform will be 100% open source」這又將掀起大家對 Android 的另一波討論。

報導表示，在與多位 Google 員工確認後知道「everything will be opened」，並且所有核心部份也都將採用 Apache software license (ASLv2)，非 core Android 部份的授權則不一定採用 ASLv2。Android 平臺是基於 Embedded Linux 系統，在 Embedded Linux 平臺上，大部份 FOSS 軟體原本就採用 GPLv2 的授權，這個部份當然不會有所變動。與 Eclipse 相關的軟體，例如 ADT (Android Development Tools plug-in) 採用的是 Eclipse Public License (EPL)。

雖然 core Android platform 將會 100% open source，但要了解的重要觀念是：

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.

開放手機平臺的演化又再進一步了。

[OSiM World（Open Source in Mobile 2008）] 將於九月17-18日於德國 Berlin 舉行，將有超過 100 位來自 Open Source Mobile 生態系統（ecosystem）的不同產業界重量級講者，為大家帶來各種不同的講題。OSiM 可說是全世界最大且影響力最強的 Open Source Mobile 研討會，有超過 42 個國家的與會者以及不同產業的領域者將出席此會議，今年的 OSiM 可說是 Open Source Mobile 的領導級活動。

倒底有哪些重量級人物將發表演說，查了一下 [Speakers] 果然不是蓋的，像是：

* Ari Jaaksi - Nokia / Open Source Operations 的 Director
* hristy Wyatt - Motorola / Software Platform & Ecosystem 的 Vice President
* Morgan Gillis - LiMo Foundation 的 Executive Director
* Benoit Schillings - Trolltech 的 Chief Technical Officer

當然，Openmoko 也沒有缺席此項盛會。Openmoko 的 founder Sean Moss-Pultz 也會出席發表演說。又看了一下 [Agenda Day 1] 以及 [Agenda Day 2] 二天的議程，「果然犀利」，其中有一個議程是我特別感興趣的：

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?

由「operator」的角度來看「Open Source」絕對是一件有意思的事。

使用 kmalloc() 時，要特別注重的是「可重覆進入」的觀念。kmalloc() 的第二個參數稱為 allocation flag，用來控制 kmalloc() 的行為，當此參數有指定 GFP_KERNEL 旗標時，kmalloc() 就是一個 blocking function。

使用 GFP_KERNEL 旗標來配置記憶體時，為什麼會有可重覆進入的議題呢？主要的關鍵在於，當 kmalloc(..., GFP_KERNEL) 無法配置記憶體時，便會做「等待」的動作，這個等待的動作是對「current process」做重排程，並等候記憶體空間。

以 open driver function 來看，通常我們會在 open driver function 裡做記憶體的配置，當記憶體目前無法取得時，open driver function 便會停止（等待），因此不會完成這一次的函數呼叫（沒有 return），此時，同一個 open driver function 會不會再被「重覆」呼叫執行呢？當然會。因為，可能會有另一個 process 去開啟 major number 相同的裝置檔，因此，同一個 open driver function 又被呼叫了，但是前一次的呼叫卻還在等待。

當函數第二次被呼叫時，第一次的呼叫還沒有結束執行，所以，函數「重覆」進來執行了。

延伸閱讀

2008.04.20: [教育訓練紀錄] 關於驅動程式的 private data 與可重覆進入函數

User application 使用 write() 函數將字串寫到裝置檔，所以在 driver 裡頭，就要實作 write system call。當字串的傳遞是透過 write system call 寫至 kernel-space 時，driver 就要使用 copy_from_user() 來讀取 user-space 的字串。以下是一個簡單的 write driver function 實作參考，此實作提供由 kernel-space 讀取 kernel-space 字串的方法，當然這裡頭包含諸多隱含在程式裡的重要關念，例如：

1. user-space page 是 valid 或 invalid。
2. 讓不同 device file 擁有私有資料結構的做法。
3. 同一個 process 在重覆進入 write driver function 時的同步問題尚未考慮，簡單來說就是同步問題還沒考慮到。

程式片段如下：

ssize_t card_write(struct file *filp, const char *buff, 
		size_t count, loff_t *offp)
{
	struct cdata_s *cdata = (struct cdata_s *)filp->private_data;
	char *str = cdata->buffer;
	int idx = cdata->idx;
	int i;
 
	if (count == 0 || count > 64) 
		goto fail1;
 
	/* get data from user-space */
	for (i = 0; i < count; i++) {
		if (idx >= 64) {
			printk(KERN_ALERT "cdata: buffer full.\n");
			goto fail2;
		}
		if (copy_from_user(str+idx, buff+i, 1))
			goto fail2;
		idx++;
	}
 
fail1:
	cdata->idx = idx;
	return 0;
fail2:
	cdata->idx = idx;
	return -EFAULT;
}

課堂中提到，這是一個 nonblocking write 的實作，後續可加入一些機制來處理 buffer full 的狀況。

在 The Wall Street Journal 上的一篇文章指出「Google 手機計畫的腳步慢下來了」，有興趣的朋友可參考原文 [Google's Mobile-Handset Plans Are Slowed]。原因是 carrier 仍與 Android 平臺奮戰中。以下是一些重點掃描，還有些許自已的想法。

Wireless carriers 要的是可以支援自家網路服務的行動裝置，而不是銷售支援其他網路服務的手機，或是自已的網路服務只是該手機的「附加功能」。由此文章也可以看出，這樣的需求，讓 wireless carriers 也開始要求手機製造商製造「branded phones」。即使像 Samsung 這樣的手機製造大廠，也面臨 carrier 要求掛品牌的問題，這方面 Samsung 並沒有什麼回應。

手機品牌廠面臨的一個問題是，當使用者需要的是能提供網路服務的手機時，勢必要和 carrier 建立良好的合作關係。當 carrier 提出的規格，是要求掛自家品牌時，像 Samsung 這樣的手機廠就會面臨一些壓力。從另一個角度來看，手機製造商（handset makers）有了另一個不錯的機會。

提供客製化的應用程式與 UI，以支援不同的網路服務，這是 carrier 使用 Android 平臺的原因。他們希望能發展客製化的 Android 應用程式，以推廣自已的網路服務，並透過服務來收費。但是在客製化 Android 軟體時，不但自已糟遇到一些問題，連手機製造商也面臨一些技術難題。

有些手機製造商花出比原先預期更多的時間，在整合與測試 Android 平臺。同時，依照 carrier 所提出的規格進行 UI 客製化時，也花費更多的時間。這是造成 Android 手機延誤上市的原因之一。

Google 必須召集更多的硬體、服務與軟體供應商來支援 Android 平臺。Google 必須解決他的 3rd party 目前所面臨的一些技術問題，這些都造成 Android 軟體發展上的沈重負擔。

為 wireless carrier 製造手機裝置是開放手機平臺公司的另外一個選擇，carrier 想要自有品牌的手機，並且想要使用 Android 平臺發展客製化的軟體平臺與 UI，以提供自有品牌的服務，而不是提供一支只有 Android 原有功能的手機。Carrier 正在思考如何提供使用者一個易於存取自有網路服務的行動裝置，看起來開放手機平臺的確有很好的機會。