和字符設備。您也許知道，典型的 /dev 樹包含數百個塊特殊文件和字符特殊文件，它們全都在根文件系統上。每個特殊文件都可以讓用戶空間進程輕松地與內核設備實現交互。舉例來說，通過對這些特殊文件執行操作，您的 X 服務器就能夠訪問視頻硬件， fsck 可以執行文件系統檢驗， lpd 可以通過並行端口向打印機發送數據。
實際上，通常 Linux 和 Unix 更“酷”的方面是，設備不是簡單地隱藏在晦澀的 API 之後，而是真正地與普通文件、目錄和符號鏈接一樣存在於文件系統上。因為字符和塊設備是映射到普通文件系統名稱空間的，我們通常可以用有意義的方式來與硬件交互，可以僅使用標准 Unix 命令，如 cat 和 dd。除了有趣之外，這還使我們有更強的能力，並提高生產力。
設備管理問題
然而，雖然設備特殊文件本身是一件好事情，但典型的 Linux 系統以一種不太理想而且麻煩的方式管理這些特殊文件。 如今，Linux 支持 很多不同種類的硬件。這意味著嚴格意義上我們中絕大多數在 /dev 中都有數百個特殊文件來表示所有這些設備。還不止這樣，這些特殊文件中大多數甚至不會映射到系統中存在的設備上（但需要它們存在，只是考慮到我們最終會在系統中添加新的硬件／驅動器），這讓事情變得更令人困惑。
僅從這個方面來看，我們就知道 /dev 需要徹底檢修，而創建 devfs 的明確目的就是讓 /dev 變回原形。為了很好地理解 devfs 是怎樣解決絕大多數 /dev 管理問題的，我們從設備驅動程序的角度來看看 devfs。
設備管理內幕
為了很好地理解 devfs ，最好是先理解從設備驅動程序的角度來看 devfs 是怎樣改變事物的。傳統地（不使用 devfs），根據是否注冊在 塊設備或 字符設備，基於內核的設備驅動程序通過調用 register_blkdev()或 register_chrdev() 向系統的其余部分注冊設備。
您必須提供一個 主設備號（一個無符號 8 位整數）作為 register_blkdev()或 register_chrdev() 的參數；然後，在設備注冊之後，內核就會知道這個特定的主設備號對應於執行 register_--?dev()調用的特定設備驅動程序。
那麼，設備驅動程序開發人員為調用 register_--?dev() 提供的主設備號 應該是什麼呢？如果開發人員不打算將設備驅動程序與外界共享，那麼什麼號碼都可以，只要它與當前內核使用的其它主設備號都不沖突即可。開發人員還可以選擇動態地分配 register_--?dev() 調用的設備的主設備號。然而，這樣的解決方案通常只是在驅動程序不會被其它人使用的情況下可行。
獲取號碼
然而，如果開發人員想讓驅動程序與外界共享（大多數 Linux 開發人員常常采用這一方法），那麼僅僅從“真空”中抽一個主設備號或者使用動態的主設備號分配就不行了。相反，開發人員必須聯系 Linux 內核開發人員，這樣他（她）的特定的設備才能分配一個“正式”主設備號。那麼，在整個 Linux 世界中，這個特定的設備（也 只有這個設備）才會被關聯到那個特定的主設備號。
有一個“正式的”主設備號很重要，因為要與特定的設備交互，管理員必須在 /dev 創建一個特殊文件。當設備節點（特殊文件）創建後，它使用的主設備號必須同內核內部使用的完全相同。這樣，進程對設備執行操作時，內核就會知道應該引用什麼設備驅動程序。讓特殊文件到內核驅動程序的映射成為可能的是主設備號，而不是真實的設備名稱（它和非 devfs 系統無關）。
一旦設備驅動程序具備正式主設備號，設備就可以被公開使用了，設備節點也就可以開始並入不同分發版的 /dev 樹，還有它們的正式 /dev/MAKEDEV 腳本（用來幫助超級用戶用正確的主從設備號、權限和所有權創建設備節點的特殊腳本）中。
傳統的問題
不幸的是，這種方法有很多可伸縮性問題。不僅設備驅動程序開發人員聯系內核開發人員來獲取正式主設備號是一件討厭的事，內核開發人員弄清他們怎樣分配所有這些主設備號甚至更加惱人。這種任務在很多方面很象系統管理員跟蹤公司局域網靜態 IP 地址分配的工作 ― 這並不十分有趣。正如系統管理員可以利用 DHCP 來緩解這種管理負擔，如果設備注冊有某種類似的方法就好了。
不只是這樣，Linux 還正在耗盡主設備號和副號碼。雖然這種問題可以通過簡單地擴展主設備號和副號碼使用的位數，首先維護這些主設備號映射就很討厭了，所以我們又在考慮有沒有更好的方法來處理這些事情。幸運的是，有這樣的方法；進入 devfs。
進入 devfs
devfs_register()
這裡是對 devfs 如何一下子處理事情和解決這些問題的一個簡單明了的快速綱要。一旦 devfs 被正確配置（包括在內核添加 devfs 支持和對啟動腳本進行一些稍復雜的更改），超級用戶重新啟動系統。然後內核開始啟動，設備驅動程序開始向系統的剩余部分注冊設備。您會記起在非 devfs 系統上， register_blkdev()和 register_chrdev() 調用（連同提供的主設備號）正是用於這一目的。然而，現在啟用了 devfs，設備驅動程序是用一種新的、改進了的內核調用來注冊設備，稱為 devfs_register()。
這裡是 devfs_register() 調用有趣的地方。雖然為了兼容性目的指定主設備號和副號碼作為參數是可能的，但不再需要這樣了。相反， devfs_register()調用接受 設備路徑（就是它在 /dev 下可能的出現形式）作為參數。舉例來說，假設 foo 設備驅動程序希望使用 devfs 注冊設備。它會提供一個 foo0 的參數給 devfs_register()，從而告訴內核應該在 devfs 名稱空間的根目錄創建一個新的 foo0 設備。相應的， devfs_register() 在 devfs 名稱空間的根目錄添加 foo0設備節點，並記錄這個新的 foo0 節點應該映射到內核中的 foo設備驅動程序。
運行的 Devfs
一旦所有設備驅動程序啟動並向內核注冊適當的設備，內核就啟動 /sbin/init 和系統初始化腳本開始執行。在啟動過程初期（在文件系統檢查前），rc 腳本將 devfs 文件系統安裝在 /dev 中，/dev 包含了 devfs 名稱空間的表達。這意味著在安裝 /dev 後，所有注冊的設備（如上面的 /dev/foo0）都可以訪問，就象在非 devfs 上一樣。當它們被訪問時，內核 通過 devfs 設備名稱映射到合適的設備驅動程序，而不是通過主設備號。
這種系統的優點是，所有需要的設備節點（沒有別的了）都由內核自動創建。這不僅僅意味著不再需要 MAKEDEV（因為所有注冊的設備都只“出現”在 /dev 中），還意味著 /dev 不再被成百個“無用的”設備節點所充斥。實際上，使用 devfs，您可以只要查看 /dev 就知道系統上有什麼設備。所以，如果您有一台支持熱插拔的膝上型電腦，這意味著您甚至可以在您從系統中插入和拔出 PC 卡時魔術般地讓設備從 /dev 中出現和消失。這讓 devfs 成為對以前笨拙局面的一個非常徹底和實用的解決方案。
devfs 的優點
Devfs 讓很多事變得容易許多。請考慮一下創建一張 Linux 可引導光盤的問題，它包括一個位於 CD 上的引導裝載器、一個 initrd、一個內核和一個回送文件系統。當 CD 引導時，引導裝載器裝載內核和 initrd，然後內核執行 initrd 上的 /linuxrc腳本。 /linuxrc 的主要任務是安裝 CD，從而使回送文件系統本身也可以被安裝和訪問。
沒有 devfs， linuxrc 就需要“查看” /dev 中的很多特殊文件，它們可能有也可能沒有表示連接到系統的真實硬件。例如， linuxrc 會需要檢測 /dev/hdc、/dev/scd0、/dev/hdb 和其它的設備以檢測“活動的”光盤驅動器設備。在檢測進程中，很可能命中幾個“無用的”設備節點。
然而，使用 devfs， linuxrc 只在 /dev/cdroms 中尋找，它包含了系統中所有和 活動的光盤驅動器相關聯的特殊文件，不管是 IDE 的還是 SCSI 的。由於這種便捷的新式 devfs 約定，再不需要猜測了；只有活動的設備才會列出，而且設備檢測代碼甚至不必擔心底層的光盤驅動器的細節，比如說它使用什麼 IDE 通道或者什麼 SCSI ID。實際上，這是 devfs 的另一個主要好處；在我下一篇文章中，我們會看到 devfs 下 /dev 中的設備有全新的缺省位置。
實際上，如果您想訪問一個特定的塊設備（如磁盤、分區、光盤驅動器等等），事實上有 幾個不同的特殊文件可以引用。例如，我的服務器只有一個 SCSI 光盤驅動器；如果啟用了 devfs，我就可以通過安裝 /dev/cdroms/cdrom0 或 /dev/scsi/host0/bus0/target4/lun0/cd 訪問它。兩種都引用同一個設備，我可以引用我認為最方便的特殊文件。如果願意，我還可以使用一種老式的設備名稱（/dev/sr0）訪問光盤驅動器，這都是因為有一個非常便捷的叫 devfsd的小程序。 devfsd 是一個有功能很多的程序，它負責創建老式的“兼容性”特殊文件，還允許您以很多種方式自定義 /dev。在我的下一篇文章中，我們會詳細討論 devfsd，到時我會一直引導您啟動 devfs 並在您自己的系統上運行它。