轉自 http://blog.csdn.net/lizzywu/article/details/5985428
注：由於原文亂碼，我稍作處理，貼在下面。
udev專題共九篇，除第一篇看本篇，其它8篇可看下面鏈接文章。
- udev（一）-- 什麼是udev
- udev（二）：man 7 udev
- udev（三）：主次設備號
- udev（四）：設備的命名問題
- udev（五）：devfs
- udev（六）：udev
- udev（七）：/dev、devfs、 udev和sysfs之間的關係
- udev（八）：實戰：使用udevadm修改usb優盤在/dev下的名字
- udev（九）-- 寫個程序檢測我們的設備插拔
什麼是udev，在網上搜索一下可以得到很多關於udev的信息，個人總結如下。
一、什麼是udev
《system:udev原理分析》 ：http://www.turbolinux.com.cn/turbo/wiki/doku.php?id=system:udev%E5%8E%9F%E7%90%86%E5%88%86%E6%9E%90）：
在linux系統中,/dev目錄用來保存設備文件的.每個文件指向一個系統設備.用戶的程序可以通過使用這些設備文件,
對真實的硬件的設備進行操作.如: hda是第1個IDE硬盤,sda是第1個SCSI硬盤.
在2.4內核時代,在/dev下保存了所有kernel可以支持的硬件設備的設備文件,將近有1萬個.而這些設備中,大多數
是沒有連接的設備.這樣就大大的浪費了系統資源,而且/dev目錄也顯得非常混亂.
udev 就是用瞭解決這些問題的.在2.6內核中,採用udev 方式來管理/dev目錄.它可以動態的建立/刪除設備文件(設備
連接到系統時,它會自動建立相應的設備文件,設備斷開連接後,它會自動刪除相應的設備文件).這樣使/dev目錄
簡化了許多.而且,udev 還可以允許用戶編寫命名規則,爲不同設備指定設備文件名.這樣,對設備的管理也方便了
許多.
例如:你有2個U盤,1個容量是1G的,1個容量是2G的.一般情況下,你先接上的U盤會是sdb,後接上的U盤會是sdc.這樣對
使用很不方便.每次U盤的設備名可能不一樣.但通過udev 命名規則,你可以自己指定的設備命名,可以將1G的U盤命名爲
1g,將2G的U盤命名爲2g.設備名不會再變化.使用和管理都會很方便.
《udev實現原理》－－ 李先靜（http://blog.csdn.net/absurd/archive/2007/04/27/1587938.aspx）
相對於 linux 來說， udev 還是一個新事物。然而，儘管它 03 年纔出現，儘管它很低調 ( J ) ，但它無疑已經成爲 linux 下不可或缺的組件了。 udev 是什麼？它是如何實現的？最近研究 Linux 設備管理時，花了一些時間去研究 udev 的實現。
udev 是什麼？ u 是指 user space ， dev 是指 device ， udev 是用戶空間的設備驅動程序嗎？最初我也這樣認爲，調試內核空間的程序要比調試用戶空間的程序複雜得多，內核空間的程序的 BUG 所引起的後果也嚴重得多， device driver 是內核空間中所佔比較最大的代碼，如果把這些 device driver 中硬件無關的代碼，從內核空間移動到用戶空間，自然是一個不錯的想法。
但我的想法並不正確， udev 的文檔是這樣說的，
1. dynamic replacement for /dev 。作爲 devfs 的替代者，傳統的 devfs 不能動態分配 major 和 minor 的值，而 major 和 minor 非常有限，很快就會用完了。 udev 能夠像 DHCP 動態分配 IP 地址一樣去動態分配 major 和 minor 。
2. device naming 。提供設備命名持久化的機制。傳統設備命名方式不具直觀性，像 /dev/hda1 這樣的名字肯定沒有 boot_disk 這樣的名字直觀。 udev 能夠像 DNS 解析域名一樣去給設備指定一個有意義的名稱。
3. API to access info about current system devices 。提供了一組易用的 API 去操作 sysfs ，避免重複實現同樣的代碼，這沒有什麼好說的。
我們知道，用戶空間的程序與設備通信的方法，主要有以下幾種方式，
1. 通過 ioperm 獲取操作 IO 端口的權限，然後用 inb/inw/ inl/ outb/outw/outl 等函數，避開設備驅動程序，直接去操作 IO 端口。（沒有用過）
2. 用 ioctl 函數去操作 /dev 目錄下對應的設備，這是設備驅動程序提供的接口。像鍵盤、鼠標和觸摸屏等輸入設備一般都是這樣做的。
3. 用 write/read/mmap 去操作 /dev 目錄下對應的設備，這也是設備驅動程序提供的接口。像 framebuffer 等都是這樣做的。
上面的方法在大多數情況下，都可以正常工作，但是對於熱插撥 (hotplug) 的設備，比如像 U 盤，就有點困難了，因爲你不知道：什麼時候設備插上了，什麼時候設備拔掉了。這就是所謂的 hotplug 問題了。
二、爲什麼使用udev
《 紅旗工程師大講堂：掌握udev》：http://linux.chinaitlab.com/administer/782422.html
在此之前的設備文件管理方法(靜態文件和devfs)有幾個缺點：
◆不確定的設備映射。特別是那些動態設備，比如USB設備，設備文件到實際設備的映射並不可靠和確定。舉一個例子：如果你有兩個USB打印機。 一個可能稱爲 /dev/usb/lp0,另外一個便是/dev/usb/lp1。但是到底哪個是哪個並不清楚，lp0,lp1和實際的設備沒有一一對應的關係，因爲他 可能因爲發現設備的順序，打印機本身關閉等原因而導致這種映射並不確定。理想的方式應該是：兩個打印機應該採用基於他們的序列號或者其他標識信息的唯一設 備文件來映射。但是靜態文件和devfs都無法做到這點。
◆沒有足夠的主/輔設備號。我們知道，每一個設備文件是有兩個8位的數字：一個是主設備號，另外一個是輔設備號來分配的。這兩個8位的數字加上設備類型(塊設備或者字符設備)來唯一標識一個設備。不幸的是，關聯這些身邊的的數字並不足夠。
◆/dev目錄下文件太多。一個系統採用靜態設備文件關聯的方式，那麼這個目錄下的文件必然是足夠多。而同時你又不知道在你的系統上到底有那些設備文件是激活的。
◆命名不夠靈活。儘管devfs解決了以前的一些問題，但是它自身又帶來了一些問題。其中一個就是命名不夠靈活;你別想非常簡單的就能修改設備文件的名字。缺省的devfs命令機制本身也很奇怪，他需要修改大量的配置文件和程序。;
◆內核內存使用，devfs特有的另外一個問題是，作爲內核驅動模塊，devfs需要消耗大量的內存，特別當系統上有大量的設備時(比如上面我們提到的系統一個上有好幾千磁盤時)
udev的目標是想解決上面提到的這些問題，他通採用用戶空間(user-space)工具來管理/dev/目錄樹，他和文件系統分開。知道如何改變缺省配置能讓你之大如何定製自己的系統，比如創建設備字符連接，改變設備文件屬組，權限等。
三、udev的使用
《linux udev的認識》：http://www.91linux.com/html/article/network_memory/20090603/17070_2.html#
問：udev怎樣做到不管設備連接的順序而維持一個統一的設備名？
答：實際上，udev是通過對內核產生的設備名增加別名的方式來達到上述目的的。前面說過，udev是用戶模式程序，不會更改內核的行爲。因此，內核依然會我行我素地產生設備名如sda,sdb 等。但是，udev可以根據設備的其他信息如總線（bus），生產商（vendor）等不同來區分不同的設備，併產生設備文件。udev只要爲這個設備文件取一個固定的文件名就可以解決這個問題。在後續對設備的操作中，只要引用新的設備名就可以了。但爲了保證最大限度的兼容，一般來說，新設備名總是作爲一個對內核自動產生的設備名的符號鏈接（link）來使用的。
例如：內核產生了sda設備名，而根據信息，這個設備對應於是我的內置硬盤，那我就可以制定udev規則，讓udev除了產生/dev/sda設備文件外，另外創建一個符號鏈接叫/dev/internalHD。這樣，我在 fstab文件中，就可以用/dev/internalHD來代替原來的 /dev/sda了。下次，由於某些原因，這個硬盤在內核中變成了sdb設備名了，那也不用着急，udev還會自動產生/dev/internalHD這個鏈接，並指向正確的/dev/sdb設備。所有其他的文件像fstab等都不用修改。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
基於上面的引用，讀者大概都可以知道什麼是udev和udev有什麼用這些基本的概念了。
更進一步的udev的信息，可以通過在linux下運行：man 7 udev查看。