# 7.4\. LFS 系統的設備和模塊處理 在 [Chapter 6](../chapter06/chapter06.html) 里，我們安裝了 Udev 軟件包，在開始深入討論它如何工作之前，我們先簡要回顧一下以前處理設備的方法。 傳統上一般 Linux 系統使用創建靜態設備的方法，因此在 `/dev` 目錄下創建了大量的設備節點(有時會有數千個節點)，而不管對應的硬件設備實際上是否存在。這通常是由 `MAKEDEV` 腳本完成的，這個腳本包含許多調用 `mknod` 程序的命令，為這個世界上可能存在的每個設備創建相應的主設備號和次設備號。而使用 udev 方式的時候，只有被內核檢測到的設備才為其創建設備節點。因為每次系統啟動的時候都要重新創建這些設備節點，所以它們被存儲在 `tmpfs` 文件系統(一種完全存在于內存里，不占用任何磁盤空間的文件系統)上，設備節點不需要很多磁盤空間，所占用的內存可以忽略不計。 ## 7.4.1\. 歷史 2000 年 2 月的時候，2.3.46 版本的內核引入了一種稱為 `devfs` 的文件系統，在 2.4 系列穩定版本的內核中都是可用的。盡管它存在于內核源代碼中，但這種動態創建設備的方法卻從未得到核心內核開發者們的全力支持。 `devfs` 存在的主要的問題是它處理設備檢測、創建和命名的方式，其中設備節點的命名可能是最嚴重的問題。一般可接受的方式是，如果設備名是可配置的，那么設備命名 策略應該由系統管理員決定，而不是由某些開發者強制規定。`devfs` 文件系統還存在競爭條件(race conditions)的問題，這是它天生的設計缺陷，不對內核做徹底的修改就無法修正這個問題。因為近來缺乏維護，它已經被標記為 deprecated(反對的)。 隨著非穩定的 2.5 內核樹的開發，即后來發布的 2.6 系列穩定版本內核，一種被稱為 `sysfs` 的新虛擬文件系統誕生了。`sysfs` 的工作是把系統的硬件配置視圖導出給用戶空間的進程。由于有了這個用戶空間可見的表示，代替 `devfs` 方案的時機就成熟了。 ## 7.4.2\. Udev 實現 #### 7.4.2.1. Sysfs 文件系統 上面簡單的提到了 `sysfs` 文件系統，您可能想知道 `sysfs` 是怎么認出系統中存在的設備以及應該使用什么設備號。對于已經編入內核的驅動程序，當被內核檢測到的時候，會直接在 `sysfs` 中注冊其對象；對于編譯成模塊的驅動程序，當模塊載入的時候才會這樣做。一旦掛載了 `sysfs` 文件系統(掛載到 `/sys`)， 內建的驅動程序在 `sysfs` 注冊的數據就可以被用戶空間的進程使用，并提供給 `udev` 以創建設備節點。 #### 7.4.2.2\. Udev 啟動腳本 `S10udev` 初始化腳本負責在 Linux 啟動的時候創建設備節點，該腳本首先將 `/sbin/udevsend` 注冊為熱插拔事件處理程序。熱插拔事件(隨后將討論)本不應該在這個階段發生，注冊 `udev` 只是為了以防萬一。然后 `udevstart` 遍歷 `/sys` 文件系統，并在 `/dev` 目錄下創建符合描述的設備。例如，`/sys/class/tty/vcs/dev` 里含有"7:0"字符串，`udevstart` 就根據這個字符串創建主設備號為 _7_ 、次設備號為 _0_ 的 `/dev/vcs` 設備。`udevstart` 創建的每個設備的名字和權限由 `/etc/udev/rules.d/` 目錄下的文件指定的規則來設置，這些文件以類似于 LFS 啟動腳本風格的編號。如果 `udev` 找不到所創建設備的權限文件，就將其權限設置為缺省的 _660_ ，所有者為 _root:root_ 。 上面的步驟完成后，那些已經存在并且已經內建驅動的設備就可以使用了，那么以模塊驅動的設備呢？ 前面我們提到了"熱插拔事件處理程序"的概念，當內核檢測到一個新設備連接時，內核會產生 一個熱插拔事件，并在 `/proc/sys/kernel/hotplug` 文件里查找處理設備連接的用戶空間程序。`udev` 初始化腳本將 `udevsend` 注冊為該處理程序。當產生熱插拔事件的時候，內核讓 `udev` 在 `/sys` 文件系統里檢測與新設備的有關信息，并為新設備在 `/dev` 里創建項目。 這樣帶來了 `udev` 存在的一個問題，之前 `devfs` 也存在同樣的問題。這通常是個"先有雞 還是先有蛋"問題。大多數 Linux 發行版通過 `/etc/modules.conf` 配置文件來處理模塊加載，對某個設備節點的訪問導致相應的內核模塊被加載。對 `udev` 這個方法就行不通了，因為在模塊加載前，設備節點根本不存在。為了解決這個問題，在 LFS-Bootscripts 軟件包里加入了 `S05modules` 啟動腳本，以及 `/etc/sysconfig/modules` 文件。通過在 `modules` 文件里添加模塊名，就可以在系統啟動的時候加載這些模塊，這樣 `udev` 就可以檢測到設備，并創建相應的設備節點了。 注意，在慢速的機器上，或者對于需要創建大量設備節點的驅動程序，創建設備的過程可能需要好幾秒鐘，這意味著某些設備節點不能立即訪問到。 #### 7.4.2.3.? 設備節點創建 為了得到正確的主次設備號，Udev 依賴于 `/sys 目錄下的` `sysfs 提供的信息。`例 如， `/sys/class/tty/vcs/dev` 包含字符串 "7:0"，被 `udevd` 用來創建主設備號是7、次設備號是0的設備節點。在 `/dev` 目錄下創建的設備節點的名字和權限由`/etc/udev/rules.d/ 目錄下相應的規則決定。`這 些以類似的形式包含在 LFS-Bootscripts 包中。 如果 `udevd` 不能為它現在創建的設備發現一個規則，它會默認把權限設置為 660 ，屬主設置為 _root: root。_Udev 規則語法的文檔可以查看 `/usr/share/doc/udev -096/index.html。` #### 7.4.2.4\. 模塊加載 被編譯成模塊的設備驅動可能有編譯進去的別名。別名可以通過 `modinfo` 程序的輸出來查看，通常與設備總線特 有的標識有關（模塊要支持）。例如，_snd-fm801_ 驅動支持 PCI 設備，通過生產廠商 ID 0x1319 和設備 ID 0x0801，有一個別名"pci:v00001319d00000801sv*sd*bc04sc01i*"。 對于大多數的設備，總線驅動通過 `sysfs` 導出可能會處理的設備驅動的別名。例如，`/sys/bus/pci/devices/0000:00:0d.0/modalias` 文件可能包含字符串"pci:v00001319d00000801sv00001319sd00001319bc04sc01i00"。 LFS 安裝的規則會導致 `udevd` 調用 `/sbin/modprobe` 處理熱插拔事件環境變量 `MODALIAS` 的內容（應該與 sysfs 中的 modalias 文件的內容一樣）。 因此在通配符擴展之后，加載所有的別名匹配這個字符串的模塊。 這個例子中，除了 _snd-fm801_，荒廢的（不想要的） _forte_ 驅動會被加載（如果它是有效的）。 查看下面的方法來避免加載不想要的模塊。 內核能在后臺加載有關網絡協議、文件系統和 NLS（國際語言支持） 支持的模塊。 #### 7.4.2.5. 處理可熱插拔/動態設備 當您插入一個設備，例如一個 USB 接口的 MP3 播放器，內核會檢測到設備連接，并產生一個熱插拔事件，如果驅動程序已經加載(要么是因為驅動已經編入內核，要么是已經通過 `S05modules` 啟動腳本加載了)，`udev` 將被調用，并根據 `/sys` 目錄下的 `sysfs` 數據來創建相應的設備節點。如果該設備的驅動是一個未加載的模塊，將設備連接到系統上只會讓內核的總線驅動產生一個熱插拔事件，通知用戶空間有新設備連 接，但并不加載驅動。事實上，什么都沒有做，設備仍然不能使用。 如果剛才插入的設備有一個驅動程序模塊但是尚未加載，Hotplug 軟件包就有用了，它就會響應上述的內核總線驅動熱插拔事件并加載相應的模塊，為其創建設備節點，這樣設備就可以使用了。 ## 7.4.3\. 創建設備的問題 自動創建設備節點的時候，存在一些已知的問題： #### 7.4.3.1. 內核模塊沒有自動加載 如果有一個總線特有的別名，并且總線驅動器導出必需的別名到 `sysfs，`那么 Udev 將只會加載一個模塊。在其他情況下，需要安排其他的模塊加載方式。在 Linux-2.6.16.27 中，Udev 為INPUT, IDE, PCI, USB, SCSI, SERIO 和 FireWire 設備加載適當的驅動。 為了確定你請求的設備驅動 Udev是否支持，可以以模塊的名字為參數運行 `modinfo`。 現在把設置設備目錄到 `/sys/bus` ，檢測那里是否有一個 `modalias` 文件。 如果 `modalias` 文件存在于 `sysfs` 中，驅動程序支持設備可以直接通信，但是沒有別名，這是驅動中的一個 bug。不利用 Udev 的幫助加載驅動，希望在以后這個問題會被修正。 如果在 `/sys/bus下的`相應目錄內沒有 `modalias` 文件，這就意味著內核開發者沒有添加對這種總線類型的模塊別名支持。在 Linux-2.6.16.27中，ISA 總線就是這種情況。希望在下個內核版本中會修正這個問題。 Udev 根本不會加載 "封裝" 驅動像 _snd-pcm-oss_，和 非硬件驅動器像 _loop_。 #### 7.4.3.2. 內核模塊沒有自動加載，并且 Udev 也不加載 如果 “封裝” 模塊增強其他模塊提供的功能（例如，_snd-pcm-oss_ 增強 _snd-pcm_ 的功能，使聲卡對于 OSS 程序可用），配置 `modprobe` 使其在加載了相應模塊后加載其封裝模塊。在 `/etc/modprobe.conf 中`添加一個 "install"? 行來實現，例如： ``` install snd-pcm /sbin/modprobe -i snd-pcm ; \ /sbin/modprobe snd-pcm-oss ; true ``` 如果模塊不是一個封裝，而是對自己本身有用，配置 `S05modules` 啟動腳本使其在系統啟動的時候加載。 要實現這個，在 `/etc/sysconfig/modules 文件的相應行上添加模塊的名字。`這對于封裝模塊也有用，但不是最優的。 #### 7.4.3.3. Udev 加載了不需要的模塊 在下面例子中，對于 _forte 模塊，可以_不編譯它或者是在 `/etc/modprobe.conf 文件中`列入黑名單： ``` blacklist forte ``` 列入黑名單的模塊仍然能夠通過 `modprobe` 命令手工加載。 #### 7.4.3.4. Udev 錯誤的創建了設備或創建了錯誤的符號鏈接 如果規則匹配不是預想的設備，那么這種情況就會經常發生。例如，一個寫的很糟糕的規則通過計算機提供商匹配到一個 SCSI 硬盤（期望的）和一個一般的 SCSI 設備（錯誤的）。找出這些不合格的規則，更正他們。 #### 7.4.3.5. Udev 規則工作不可靠 這或許是前面問題的一個表現。如果不是，你的規則使用 `sysfs` 屬性，這可能是一個內核計時問題，在下個版本的內核中會被修正 。 現在，你可以通過創建一個等待使用 `sysfs 屬性`的規則，把它添加到 `/etc/udev/rules.d/10-wait_for_sysfs.rules` 文件中。如果你做了，請通知 LFS 開發郵件列表 ，對他們有所幫助。 #### 7.4.3.6. Udev 沒有創建設備 后面的文本假設驅動已經被靜態的編譯進了內核或者是作為模塊已經被加載，你已經檢查了 Udev 沒有創建錯誤的設備。 某個內核驅動可能沒有將其數據導出到 `sysfs`。這個問題在內核源代碼樹之外的第三 方驅動程序上尤其常見，結果是這些驅動無法創建其設備節點。用 `/etc/sysconfig/createfiles` 配置文件手動創建這些設備，參考內核文檔里的 `devices.txt` 文件或者該驅動的文檔以獲得正確的主/次設備號。 靜態的設備將會被 **S10udev 啟動腳本**拷貝到 `/dev`。 #### 7.4.3.7. 重啟后設備名字順序變化 這是由于 Udev 設計的問題，它以并行方式處理熱插拔事件和加載模塊。因此名字的順序就會不可預測。 這將不會被修正。你不應當依賴內核設備名字會穩定。相應的，根據設備穩定的屬性（比如，序列號或者 Udev 安裝的各種 *_id 工具的輸出）寫自己 的規則來創建符號鏈接。可以參見 [節 7.12, "為設備創建慣用符號連接"](symlinks.html "7.12\. 為設備創建慣用符號連接") 和 [節 7.13, "配置網絡腳本"](network.html "7.13\. 配置網絡腳本") 。