udev

 傳統靜態設備創建，量設備節 / 創建（千），管硬體設備否存。腳，腳本包含了許多通過世界上（有幽默意味，注）每一個可能存在的設備相關的主設備號和次設備號對mknod程序的調用。採用udev的方法，只有被內核檢測到的設備才會獲取為它們創建的設備節點。因為這些設備節點在每次系統啟動時被創建，他們會被貯存在ramfs（一個內存中的文件系統，不佔用任何磁碟空間）.設備節點不需要大量磁碟空間，因此它使用的內存可以忽略。

.版，件系統稱添。儘管核源碼，核態創建設備未壓倒支持；

式：設備檢測，創建，。設備節，。普遍設備允配置，設備策略該取決系統管理員，而不是devfs的開發者。文件系統同時還忍受著一個紊亂情況，為它的設計所固有，且不能被修復，因無實質的修改現由於缺乏維護已被丟棄內核。

在2.6版本的內核中，出現了一種叫sysfs的新虛擬文件系統。該文件系統將其搬到用戶空間進程。有了這種用戶空間可見表示法，使文件系統變得更加現實、且具有用戶可更換性。

sysfs怎樣知道設備出現在系統應該使用什麼設備號？？對於被編進內核的驅動，當被內核監測到時，直接註冊目標與sysfs。使用模塊方式編譯的，當模塊被負荷時，如前。一旦sysfs文件系統被安裝（在/sys），其內置的驅動程序註冊sysfs的數據提供給用戶空間進程和設備節點創建udev。

udev初始化腳本創建這些設備節點當Linux啟動時；這個腳本開始註冊/sbin/udev/ 作為一個hotplug event管理者。hotplug event不應該發生在這個過程中，然而udev註冊以防萬一他們發生。然後udevstart程序走通過/sys文件系統和創建符合描述的設備在/發展例如：/系統/班/電傳/風投/ dev /包括字元串“7:0”這個字元串被。udevstart使用來創建/ dev 例如，主設備號7和次設備號0。每一個udevstart創建的設備的許可權設置來自/etc/udev.d/permission.d/目錄。這些編號（有限的）基本相似LFS啟動腳本。如果找不到創建的設備許可權文件，默認許可權600，所有者root：root 目錄下創建的節點根據 /etc/udev/rules.d/目錄下的文件來配置。

當一個新設備連 接被kernel監測到，kernel會產生一個hotplug event 並查找/proc/sys/kernel/hotplug去找出管理設備連接的用戶空間程序。udev初始化腳本註冊udev as this hander.當hotplug events發生時，kernel通知udev 去檢測/sys 文件系統附屬於這個新設備的信息並create 它的/dev/入口。

這帶給我們一個問題：exists with udev,and likewise with devfs before it.？就像先有雞還是先有蛋。大部分linux distrubtions

管 理載入模塊通過/etc/modules.conf.access to 設備節點引起相應的kernel模塊來載入。然而對於udev，這種方法不能正常工作，因為模塊沒有載入時，設備節點不存在。為了解決這個問題，模塊腳本 加到了lfs-bootscripts包中，和/etc/sysconfig/modules在一起。通過添加module names到module file中，這些模塊在計算機啟動時被載入。這樣，udev就可以去檢測設備並創建相應的設備節點。

3：處理可熱插拔/動態設備

當 你插入一個設備，比如usb mp3 player,內核辨認出設備連接同時產生一個熱插拔事件。如果驅動已經loaded(不管是編進kernel還是通過s05modules bootscript載入），udev將被調用來創建相關的設備節點，根據sysfs data in /sys.如果剛插入的設備驅動以模塊形式然而並未載入，那麼剛attach to system 的設備只會引起kernel匯流排驅動產生一個熱插拔事件通知用戶空間一個新設備的連接and它不attached to a driver.結果，什麼都沒有發生，device依然不能使用。

如果建立一個system,that具有大量的以模塊形式編譯的驅動，使用s05modules並不實際。the hotplug package會顯得非常有價值。當此包安裝后，它會響應前述的kernel匯流排驅動hotplug事件。此包將載入相應的模塊並為設備創建節點。

4：創建設備的問題

自動創建設備節點時常遇到的一些問題

1）A kernel driver may not exports its data to sysfs

當 使用第三方驅動（在kernel source tree 之外）時常遇到這種問題。

這些驅動end up時沒有創建設備節點。使用/etc/sysconfig/creatfiles 配置文件to 人工創建設備。參考devices.txt文件（在kernel文檔中）或者驅動文檔來找出正確的major/minor設備號。

2）無硬體設備 is required.這種很常見with the advanced linux sound architecture(ALSA) project's open sound system(oss) compatibility 模塊。這種形式的驅動可以使用以下下面兩種方法來管理：

*將module names 加到 /etc/sysconfig/modules;

* 使用"install"line 在/etc/modprobe.conf中。This tells the modprobe command "when loading this module,also load this other module,at the same time."例如

install snd-pcm modprobe -i snd-pcm;modprobe snd-pcm-oss;true

當系統中有載入snd-pcm驅動的請求時，這會使系統載入both snd-pcm and snd-pcm-oss modules.

問： udev是什麼? 它的目的何在?

答：看看那篇 OLS 2003 上的有關 udev 的文章吧，可以在 docs 目錄里找到，也能在這

里找到：OLS 2003 上還有一個關於 udev 的幻燈片。

問： udev 和 devfs 是什麼關係

答： udev 完全在用戶態 (userspace) 工作，利用設備加入或移除時內核所發送的

hotplug 事件 (event) 來工作。關於設備的詳細信息是由內核輸出 (export) 到位

於 /sys 的 sysfs 文件系統的。所有的設備命名策略、許可權控制和事件處理都是在

用戶態下完成的。與此相反，devfs 是作為內核的一部分工作的。

問：如果 udev 不能完成所有 devfs 的工作的話，為什麼把 devfs 標記為

OBSOLETE/removed?

答：引用 Al Viro (Linux VFS 內核維護者）：

- devfs 所做的工作被確信可以在用戶態來完成。

- devfs 被加入內核之時，大家寄望它的質量可以迎頭趕上。

- devfs 被發現了一些可修復和無法修復的 bug。

- 對於可修復的 bug，幾個月前就已經被修復了，其維護者認為一切良好。

- 對於後者，同樣是相當常一段時間以來沒有改觀了。

- devfs 的維護者和作者對它感到失望並且已經停止了對代碼的維護工作。

問：但是當一個並不存在的 /dev 節點被打開的時候，udev 並不能如 devfs 一樣自動加

載驅動程序。

答：的確如此，但 Linux 的設計是在設備被發現的時候載入模塊，而不是當它被訪問的時

候。

問：不過等等，我確實希望 udev 可以在不存在的節點被打開的時候自動載入驅動。這是

我使用 devfs 的唯一原因了。給 udev 增加這個功能吧。

答：不，udev 是用來管理 /dev 的，不是用來載入內核驅動的。

問：嗨，求你們了。這不難做到的。

答：這麼個功能對於一個配置正確的計算機是多餘的。系統中所有的設備都應該產生

hotplug 事件、載入恰當的驅動，而 udev 將會注意到這點並且為它創建對應的

設備節點。如果你不想讓所有的設備驅動停留在內存之中，應該使用其它東西來

管理你的模塊（如腳本，modules.conf，等等）這不是 udev 的工作。

問：但是我真的喜歡那個功能，還是加上吧

答： devfs 用的方法導致了大量無用的 modprobe 嘗試，以此程序探測設備是否存在。

每個試探性探測都新建一個運行 modprobe 的進程，而幾乎所有這些都是無用的。

問：我喜歡 devfs 的設備文件命名方式，udev 可以這樣命名么?

答：可以，udev 可以使用 /dev 的命名策略來創建節點。通過一個配置文件，可以把內

核預設的名字映射到 devfs 的名字。可以看看 udev 中帶的 udev.rules.devfs 文

件。

注意： devfs 的命名方式是不被建議並且不被官方支持的，因為它所用的簡單枚舉設

備的方式在設備可能被隨時加入或刪除的情況下確實是一個比較笨的方法。這些編號

代給你的將只有麻煩，而並不能用來確定設備。看看那個永久性磁碟 (persistent

disk) 的規則就知道如何在用戶態下正確的做這件事，而不是傻傻地列出設備。

問： udev 可以為哪些設備創建節點?

答：所有在 sysfs 中顯示的設備都可以由 udev 來創建節點。如果內核中增加了其它設

備的支持，udev 也就自動地可以為它們工作了。現在所有的塊設備都在被支持之列，

大部分的主字元設備也是被支持的。內核開發者們正致力於讓所有的字元設備都被支

持。可以到 linux-kernel 郵件列表上尋找補丁或是查看補丁的狀態。

問： udev 是否會去掉匿名設備數量的限制?

答： udev 完全工作於用戶態。如果內核支持了更多的匿名設備，udev 就會支持。

問： udev 是否會支持符號鏈接

答： udev 現在就支持符號鏈接，每個設備節點擁有多個符號鏈接也是被支持的。

問： udev 如何處理 /dev 文件系統?

答：建議使用一個每次啟動系統的時候重新創建的 tmpfs 作為 /dev 的文件系統。不過

實際上 udev 並不關心那種文件系統在被使用。

問：在 init 運行之前，udev 如何處理設備?

答： udev 可以被放入 initramfs 之中，並在每個設備被發現的時候運行。也可以讓

udev 工作在一個真的根分區被載入之後根據 /sys 的內容創建的初始 /dev 目錄

之中。

問：我是否可以利用 udev 在一個 USB 設備被載入的時候自動載入上這個設備?

答：技術上講是可以的，但是 udev 不是用於這個工作的。所有的主流發布版 (distro)

都包含了 HAL用於這個工作，它

也是專門用於監視設備變更的，並且集成進入了桌面軟體。

換個角度說，這可以簡單的通過 fstab 來實現：

/dev/disk/by-label/PENDRⅣE /media/PENDRⅣE vfat user,noauto 0 0

這樣，用戶可以用如下命令來訪問設備：

$mount /media/PENDRⅣE

同樣不需要管理員許可權，但卻擁有了設備的全部訪問許可權。使用永久性磁碟鏈接

（label,uuid) 將可以指定同一設備，無論其實際上的內核名字是什麼。

問：有什麼我需要注意的安全問題么?

答：當使用動態設備編號的時候，一個給定的主/從設備號可能在不同時間對應不同的設

備，如果一個用戶擁有對這個節點的訪問許可權，並且可以創建一個到這個節點的硬鏈

接，他就可以如此得到一個這個設備節點的拷貝。當設備被移除之後，udev 刪除了

設備節點，但硬鏈接依然存在。如果這個設備節點之後被重新使用不同的訪問許可權被

創建的時候，其硬鏈接仍然可以使用先前的訪問許可權來訪問。

（同樣的問題也存在在使用 PAM 改變訪問許可權的 login 上。）

簡單的解決方案就是通過把 /dev 放在 tmpfs 這樣的單獨的文件系統之上來防止建

立硬鏈接。