hal: hardware abstraction layer 硬體抽象層
這個是李先靜的blog的解釋,真是天下何處不逢君啊
hal是hardware abstraction layer的首字母縮寫。我最早是在winnt 3.5的幫助中知道這個名詞的，對幫助文件中的說法我比較認同，所以一直對它抱有好感。不過windows下的hal和linux下的hal兩者所指並非相同之物：
windows下的hal：位於作業系統的最底層，直接操作物理硬體，隔離與硬體相關的資訊，為上層的作業系統和裝置驅動程式提供乙個統一的介面，起到對硬體的抽象作用。有了hal，編寫驅動程式就容易多了，因為hal的介面不但使用簡單，而且具有更好的可移植性（沒用過）。
linux 下的hal：至於對硬體的抽象，linux核心早就有類似機制，只不過沒有專門的名稱罷了。而linux的hal指的並非這個，它不是位於作業系統的最底層，直接操作硬體，相反，它位於作業系統和驅動程式之上，是乙個執行在使用者空間中服務程式。
我們知道，linux和所有的unix一樣，習慣用檔案來抽象裝置，任何裝置都是乙個檔案，比如/dev/mouse是滑鼠的裝置檔案。這種方法看起來不錯，每個裝置都有統一的形式，但使用並不那麼容易，裝置檔名沒有什麼規範，從簡單的乙個檔名，你無法得知它是什麼裝置，具有有什麼特性。
結果形成這樣的尷尬：有了裝置和裝置驅動程式，卻不知道如何使用它。這些亂七八糟的裝置檔案，讓裝置的管理和應用程式的開發都變得很麻煩，所以有必要提供乙個硬體抽象層，來為上層應用程式提供乙個統一的介面，linux的hal就這樣應運而生了。
但hal並不提供諸如拍照和燒錄等之類的功能，相反它只是告訴應用程式，系統中有哪些裝置可用，以及這些裝置的型別、特性和能力等。主要說來，它提供以下幾項功能：
1. 獲取指定型別的裝置列表。
2. 獲取/更改裝置的屬性值。
3. 獲取裝置具有的能力描述。
4. 裝置插入/拔除時，通知相關應用程式。
5. 裝置屬性或能力變化時，通知相關應用程式。
udev建立dev下的檔案結點，載入驅動程式，讓裝置處於可用狀態。而hal則告訴應用程式，現在有哪些裝置可用，這些裝置的型別、特性和能力，讓應用程式知道如何使用它們。
udev 是 linux kernel 2.6 系列的裝置管理器。它主要的功能是管理 /dev 目錄底下的 裝置節點。它同時也是用來接替 devfs 及hotplug 的功能，這意味著它要在新增／刪除硬體時處理 /dev 目錄以及所有使用者空間的行為，包括載入 firmware 時。(udev中的u有人說是指代user？期待更「權威」的解釋 )
udev的最新版本依賴於公升級後的linux kernel 2.6.13的uevent介面的最新版本。使用新版本udev的系統不能在2.6.13以下版本啟動，除非使用noudev引數來禁用udev並使用傳統的 /dev 來進行裝置讀取。
在傳統的linux系統中，/dev目錄下的裝置節點為一系列靜態存在的檔案，而udev則動態提供了在系統中實際存在的裝置節點。雖然devfs提供了類似功能，udev的支持者也給出了很多udev實現比devfs好的理由
* udev支援裝置的固定命名，而並不依賴於裝置插入系統的順序。預設的udev設定提供了儲存裝置的固定命名。任何硬碟都根據其唯一的檔案系統id、磁碟名稱及硬體連線的物理位置來進行識別。
* udev完全在使用者空間執行，而不是像devfs在核心空間一樣執行。結果就是udev將命名策略從核心中移走，並可以在節點建立前用任意程式在裝置屬性中為裝置命名。
udev是乙個通用的核心裝置管理器。它以守護程序的方式執行於linux系統，並監聽在新裝置初始化或裝置從系統中移除時核心（通過netlink socket）發出的uevent。
系統提供了一套規則用於匹配可發現的裝置事件和屬性的匯出值。匹配規則可能命名並建立裝置節點，並執行配置程式來對裝置進行設定。udev規則可以匹配像核心子系統、核心裝置名稱、裝置的物理等屬性，或裝置序列號的屬性。規則也可以請求外部程式提供資訊來命名裝置，或指定乙個永遠一樣的自定義名稱來命名裝置，而不管裝置什麼時候被系統發現。
韌體（firmware），台灣、港澳作「韌體」，在計算機中是一種嵌入在硬體裝置中的軟體。通常它是位於快閃儲存器或eeprom和prom中，而且可以讓使用者更新。(maybe可以這麼拓展一下：hardware、firmware、software)
顧名思義，韌體的所在是位於軟體和硬體之間的。像軟體一樣，他是乙個被計算機所執行的程式。然而它是對於硬體內部而言更加貼近以及更加重要的部份，而對於外在的世界而言較無重要的意義。
韌體的示例包含:
* 個人計算機中的bios
* 昇陽計算機和蘋果計算機的計算機中使用的open firmware
* 在唯讀儲存器中的電腦程式（硬體的設定通常用軟體的方式來表示）
* 在可程式設計化唯讀儲存器中，這些程式只可以被特別的外部硬體來更改，而不能經由應用程式更新
「韌體」這個名詞是源自於為了 如amd29xx所寫之微程式之微程式。後來它被當成取代乙個低價的微處理器裡的一部分功能。
實際而言，規律的韌體的公升級可以提公升效能以及可靠性。在眾多的有規律的韌體公升級中燒錄裝置是其中之一，比如說光源燒錄器(***, cd, hd ***, blu-ray)，隨著**技術的日新月異，韌體的更新可以確保硬體保持在最新的狀態以及確保其相容性。
韌體已經演進為乙個硬體裝置當中的可程式設計化的內容，比如說韌體可能包含有一處理器之機器碼或者固定功能之裝置，或是閘道陣列或者可程式設計化之邏輯器件之設定。
韌體的乙個一般性的特色是它可以被在生產後或用電子的方式或者用取代儲存媒介的方式更新。
韌體可以 — 但並非必需 — 暴露出乙個可由外界連線的介面。比如說在某些數據機的實現中，韌體並非可以直接訪問，但卻是由硬體以及韌體所組成回應主機的一部分。
韌體原本被存放在於rom中，然而**以及效能的需求已經讓原件**商妥協於其他的替代方案，包含了非易失性的**比如說eeprom以及快閃儲存器或是sram的解決方案。
硬體抽象層 HAL
本章主要講硬體抽象層 hal硬體抽象層是建立在linux驅動之上的一套程式庫。這套程式庫並不屬於linux核心，而是屬於linux核心層上的應用層。google為android加入hal主要有以下目的 統一硬體的呼叫介面。由於hal有標準的呼叫介面，所以可以利用hal遮蔽了linux驅動複雜 不統一...
Android 硬體抽象層（HAL）
出發點 保護廠商利益 android的硬體抽象層，簡單來說，就是 對linux核心驅動程式的封裝，向上提供介面，遮蔽低層的實現細節。也就是說，把對硬體的支援分成了兩層，一層放在使用者空間 user space 一層放在核心空間 kernel space 其中，硬體抽象層執行在使用者空間，而linux...
第9章 硬體抽象層 HAL
撇開這些爭論，學習android硬體抽象層，對理解整個android整個系統，都是極其有用的，因為它從下到上涉及到了android系統的硬體驅動層 硬體抽象層 執行時庫和應用程式框架層等等，下面這個圖闡述了硬體抽象層在android系統中的位置，以及它和其它層的關係 android加入hal主要有如...