Sysfs文件系統與Linux設備模型
sysfs把連接在系統上的設備和總線(xiàn)組織成為一個(gè)分級的目錄及文件，它們可以由用戶(hù)空間存取，向用戶(hù)空間導出內核數據結構以及它們的屬性，這其中就包括設備的主次設備號。新的設備文件系統udev的工作過(guò)程就依賴(lài)于sysfs文件系統的這些功能特點(diǎn)。udev文件系統在用戶(hù)空間工作，它可以根據sysfs文件系統導出的信息（設備號（dev）等），動(dòng)態(tài)建立和刪除設備文件（下文詳細介紹），而不再需要使用mknod來(lái)手動(dòng)建立設備文件，也不必為查找設備號（尤其是驅動(dòng)中動(dòng)態(tài)申請產(chǎn)生的設備號）而頭疼。
kobject內核對象提供了基本的對象管理能力，是linux 2.6設備模型的核心結構，每個(gè)在內核中注冊的kobject對象都對應于sysfs文件系統的一個(gè)目錄，這可以通過(guò)以下函數調用體現：
kobject_add()-> kobject_add_varg()->kobject_add_internal()->create_dir()->sysfs_create_dir()
（好像已經(jīng)不存在kobject_register函數了）
sysfs文件系統下的所有目錄，其最終的建立過(guò)程都是通過(guò)注冊添加kobject到linux設備層次來(lái)實(shí)現的，舉兩個(gè)例子：
1、class
class_register-> __class_register-> kset_register-> kobject_add_internal
2、device
device_register-> device_add-> kobject_add
因此，對應于一個(gè)設備，在sysfs文件系統下不是一個(gè)文件，而是一個(gè)目錄，目錄名字的來(lái)源是kobject對象的name域。目錄中會(huì )有兩個(gè)文件和若干目錄，這兩個(gè)文件是設備的屬性文件。我們可以看看device_add函數的實(shí)現，其中有：
912 error = device_create_file(dev, &uevent_attr);
913 if (error)
914 goto attrError;
915
916 if (MAJOR(dev->devt)) {
917 error = device_create_file(dev, &devt_attr);
918 if (error)
919 goto ueventattrError;
其中會(huì )在sysfs文件系統對應設備目錄下創(chuàng )建兩個(gè)屬性文件（可以看看device_create_file函數的實(shí)現，是調用sysfs_create_file），其中有兩個(gè)參數是兩個(gè)結構體指針，兩個(gè)結構體的定義如下：
311static struct device_attribute uevent_attr =
312 __ATTR(uevent, S_IRUGO | S_IWUSR, show_uevent, store_uevent);
428static struct device_attribute devt_attr =
429 __ATTR(dev, S_IRUGO, show_dev, NULL);
再看看_ATTR:
48#define __ATTR(_name,_mode,_show,_store) {
49 .attr = {.name = __stringify(_name), .mode = _mode }, \
50 .show = _show, \
51 .store = _store, \
52 }
再看看__stringify：
19 #define __stringify_1(x) #x
20 #define __stringify(x) __stringify_1(x)
（真是無(wú)底洞呀，到這為止吧?。┻@兩個(gè)宏看起來(lái)很怪異，有人說(shuō)這個(gè)定義很奇妙，具體奇妙在哪目前我還沒(méi)體會(huì )到，等有機會(huì )再補充（留個(gè)腳印吧）。簡(jiǎn)單來(lái)說(shuō)，它們的功能就是x轉化為字符串，所以uevent和dev就轉化為“uevent”和”dev“了，把它們賦給name，這就是sysfs具體設備目錄下的兩個(gè)文件uevent和dev名字的來(lái)源了！
這兩個(gè)屬性文件的內容是怎么等到的呢？sysfs是虛擬文件系統，大家應該知道proc文件系統吧，類(lèi)似地它們都是在內存中，內容都是動(dòng)態(tài)生成的而不是存儲在非易失存儲器中。大家應該注意到屬性結構體中有兩個(gè)函數指針show和store，在這里被賦值了
422 static ssize_t show_dev(struct device *dev, struct device_attribute *attr,
423 char *buf)
424 {
425 return print_dev_t(buf, dev->devt);
426 }
您可能想知道 sysfs 是怎么認出系統中存在的設備以及應該使用什么設備號。對于已經(jīng)編入內核的驅動(dòng)程序，
當被內核檢測到的時(shí)候，會(huì )直接在 sysfs 中注冊其對象；對于編譯成模塊的驅動(dòng)程序，當模塊載入的時(shí)候才會(huì )這樣做。一旦掛載了 sysfs 文
件系統(掛載到 /sys)，內建的驅動(dòng)程序在 sysfs 注冊的數據就可以被用戶(hù)空間的進(jìn)程使用，并提供給 udev 以創(chuàng )建設備節點(diǎn)。
udev 初始化腳本負責在 Linux 啟動(dòng)的時(shí)候創(chuàng )建設備節點(diǎn)，該腳本首先將 /sbin/udevsend 注冊為熱插拔事件處理程序。熱插拔事
件(隨后將討論)本不應該在這個(gè)階段發(fā)生，注冊 udev 只是為了以防萬(wàn)一。然后 udevstart 遍歷 /sys 文件系統（其屬性文件dev中記錄這設備的主設備號，與次設備號），并在 /dev 目錄下創(chuàng )建符合描述的設備文件。例如，/sys/class/tty/vcs/dev 里含有"7:0"字符串，udevstart 就根據這個(gè)字符串創(chuàng )建主設備號為 7 、次設備號為 0 的 /dev/vcs 設備。udevstart 創(chuàng )建的每個(gè)設備的名字和權限由 /etc/udev/rules.d/ 目錄下的文件指定的規則來(lái)設置。如果 udev 找不
到所創(chuàng )建設備的權限文件，就將其權限設置為缺省的 660 ，所有者為 root:root 。
上面的步驟完成后，那些已經(jīng)存在并且已經(jīng)內建驅動(dòng)的設備就可以使用了，那么以模塊驅動(dòng)的設備呢？
前面我們提到了"熱插拔事件處理程序"的概念，當內核檢測到一個(gè)新設備連接時(shí)，內核會(huì )產(chǎn)生一個(gè)熱插拔事件，
并在 /proc/sys/kernel/hotplug 文件里查找處理設備連接的用戶(hù)空間程序。udev 初始化腳本將 udevsend 注冊為該處理程序。
當產(chǎn)生熱插拔事件的時(shí)候，內核讓 udev 在 /sys 文件系統里檢測與新設備的有關(guān)信息，并為新設備在 /dev 里創(chuàng )建項目。
大多數 Linux 發(fā)行版通過(guò) /etc/modules.conf 配置文件來(lái)處理模塊加載，對某個(gè)設備節點(diǎn)的訪(fǎng)問(wèn)導致相應的內核模塊被加載。對 udev 這
個(gè)方法就行不通了，因為在模塊加載前，設備節點(diǎn)根本不存在。為了解決這個(gè)問(wèn)題，在 LFS-Bootscripts 軟件包里加入了 modules 啟動(dòng)腳
本，以及 /etc/sysconfig/modules 文件。通過(guò)在 modules 文件里添加模塊名，就可以在系統啟動(dòng)的時(shí)候加載這些模塊，這樣 udev 就
可以檢測到設備，并創(chuàng )建相應的設備節點(diǎn)了。如果插入的設備有一個(gè)驅動(dòng)程序模塊但是尚未加載，Hotplug 軟件包就有用了，它就會(huì )響應
上述的內核總線(xiàn)驅動(dòng)熱插拔事件并加載相應的模塊，為其創(chuàng )建設備節點(diǎn)，這樣設備就可以使用了。
udev是一種工具，它能夠根據系統中的硬件設備的狀況動(dòng)態(tài)更新設備文件，包括設備文件的創(chuàng )建，刪除等。設備文件通常放在/dev目錄下，
使用udev 后,在/dev下面只包含系統中真實(shí)存在的設備。它于硬件平臺無(wú)關(guān)的，位于用戶(hù)空間，需要內核sysfs和tmpfs的支持，sysfs為
udev提供設備入口和uevent通道，tmpfs為udev設備文件提供存放空間。
顯而易見(jiàn)udev設備文件的優(yōu)點(diǎn)：
1.udev完全在用戶(hù)態(tài)工作，利用設備加入或移除時(shí)內核所發(fā)送的熱插拔事件。在熱插拔時(shí)，設備的詳細信息會(huì )由內核輸出到位于/sys的sysfs
文件系統。udev的設備命名策略權限控制都在用戶(hù)態(tài)完成的，它利用sysfs信息來(lái)進(jìn)行創(chuàng )建設備文件節點(diǎn)。
2.udev根據系統中的硬件設備的狀態(tài)動(dòng)態(tài)更新設備文件，進(jìn)行設備文件的創(chuàng )建和刪除等。
注：使用udev,/dev目錄下就會(huì )只包含系統中真正存在的設備。
注：所有在 sysfs 中顯示的設備都可以由 udev 來(lái)創(chuàng )建節點(diǎn)。如果內核中增加了其它設備的支持，
udev 也就自動(dòng)地可以為它們工作了。在init初始化之前，udev 可以被放入 initramfs 之中，并在每個(gè)設備被發(fā)現的時(shí)候運行。
也可以讓udev 工作在一個(gè)真的根分區被加載之后根據 /sys 的內容創(chuàng )建的初始 /dev 目錄之中
三.>udev和devfs設備文件的對比
1.udev能夠實(shí)現所有devfs實(shí)現的功能。但udev運行在用戶(hù)模式中，而devfs運行在內核中。
2.當一個(gè)并不存在的 /dev 節點(diǎn)被打開(kāi)的時(shí)候， devfs一樣自動(dòng)加載驅動(dòng)程序而udev確不能。
udev設計時(shí)，是在設備被發(fā)現的時(shí)候加載模塊，而不是當它被訪(fǎng)問(wèn)的時(shí)候。
devfs這個(gè)功能對于一個(gè)配置正確的計算機是多余的。系統中所有的設備都應該產(chǎn)生
hotplug 事件、加載恰當的驅動(dòng)，而 udev 將會(huì )注意到這點(diǎn)并且為它創(chuàng )建對應的
設備節點(diǎn)。如果你不想讓所有的設備驅動(dòng)停留在內存之中，應該使用其它東西來(lái)
管理你的模塊 (如腳本, modules.conf, 等等) 。
其中devfs 用的方法導致了大量無(wú)用的 modprobe 嘗試，以此程序探測設備是否存在。
每個(gè)試探性探測都新建一個(gè)運行 modprobe 的進(jìn)程，而幾乎所有這些都是無(wú)用的。
3.udev是通過(guò)對內核產(chǎn)生的設備名增加別名的方式來(lái)達到上述目的的。前面說(shuō)過(guò)，udev是用戶(hù)模式程序，不會(huì )更改內核的行為。
因此，內核依然會(huì )我行我素地產(chǎn)生設備名如sda,sdb等。但是，udev可以根據設備的其他信息如總線(xiàn)（bus），生產(chǎn)商（vendor）等
不同來(lái)區分不同的設備，并產(chǎn)生設備文件。udev只要為這個(gè)設備文件取一個(gè)固定的文件名就可以解決這個(gè)問(wèn)題。在后續對設備的操作中，
只要引用新的設備名就可以了。但為了保證最大限度的兼容，一般來(lái)說(shuō)，
新設備名總是作為一個(gè)對內核自動(dòng)產(chǎn)生的設備名的符號鏈接（link）來(lái)使用的。
例如：內核產(chǎn)生了sda設備名，而根據信息，這個(gè)設備對應于是我的內置硬盤(pán)，那我就可以制定udev規則，讓udev除了產(chǎn)生/dev/sda設備文件外，另外創(chuàng )建一個(gè)符號鏈接叫/dev/internalHD。這樣，我在fstab文件中，就可以用/dev/internalHD來(lái)代替原來(lái)的/dev/sda了。下次，由于某些原因，這個(gè)硬盤(pán)在內核中變成了sdb設備名了，那也不用著(zhù)急，udev還會(huì )自動(dòng)產(chǎn)生/dev/internalHD這個(gè)鏈接，并指向正確的/dev/sdb設備。所有其他的文件像fstab等都不用修改。
而在在2.6內核以前一直使用的是devfs，devfs掛載于/dev目錄下，提供了一種類(lèi)似于文件的方法來(lái)管理位于/dev目錄下的所有設備，但是devfs文件系統有一些缺點(diǎn)，例如：不確定的設備映射，有時(shí)一個(gè)設備映射的設備文件可能不同，例如我的U盤(pán)可能對應sda有可能對應sdb 。
注：可以用命令查看其中的信息， udevinfo -a -p /sys/block/sda
