基本信息
Linux 傳統上使用靜態設備創建方法，因此大量設備節點在 /dev 下創建（有時上千個），而不管相應的硬體設備是否真正存在。通常這由一個MAKEDEV腳本實現，這個腳本包含了許多通過世界上（有幽默意味，注）每一個可能存在的設備相關的主設備號和次設備號對mknod程式的調用。採用udev的方法，只有被核心檢測到的設備才會獲取為它們創建的設備節點。因為這些設備節點在每次系統啟動時被創建，他們會被貯存在ramfs（一個記憶體中的檔案系統，不占用任何磁碟空間）.設備節點不需要大量磁碟空間，因此它使用的記憶體可以忽略。
歷史
在kernel2.4的版本中，一種新檔案系統稱作devfs被添加了進去。儘管它出現在核心源碼中，然而核心開發者對這種動態創建設備的方法從未受到壓倒性的支持；
devfs方法主要方式：設備檢測，創建，命名。設備節點命名，可能是最重要的。人們普遍認為設備名允許是可配置的，然後設備命名策略應該取決於一個系統管理員，而不是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 這樣的單獨的檔案系統之上來防止建
立硬連結。
