Udev 基本工作原理

udev 基本工作原理

udev的****：http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html

此外，關於udev的rules規則的撰寫，網上也有很多文章，假如要獲得最準確的版本，能夠在src code的**樹里找到writing_udev_rules的幫助文件，這個文件其實沒有逐條介紹rules的任何關鍵字，能夠結合man udev 和 udev自帶的一些rules文件來理解如何撰寫您所需要的規則文件。

2 安裝和啟動

2.2 啟動

您能夠在啟動指令碼中用udevd –d 引數啟動udev文件系統的守護程序，然後使用udevtrigger將buildin的裝置驅動的節點建立出來，以後模組插入移除時節點的管理會自動處理。

能夠正常載入udev的前提，基本包括如下操作：

配置路徑變數

載入sysfs文件系統

載入乙個基於ram的可寫的/dev目錄（其實，只要提供乙個可寫的目錄即可，目錄路徑本身也是能夠配置的）

/dev目錄下需要有已建立好的 console節點和null節點

指令碼類似：

# set the path

path=/bin:/sbin:/usr/bin:/usr/sbin

export path

# mount proc and devpts filesystem

/bin/mount -a

mknod /dev/console c 5 1

mknod /dev/null c 1 3

/sbin/udevd -d

/sbin/udevtrigger

mount使用的fstab文件類似：

none /tmp ramfs defaults 0 0

udev /dev ramfs defaults 0 0

none /proc proc defaults 0 0

sysfs /sys sysfs defaults 0 0

當然，您的系統上可能還會需要預先建立一些其他的裝置節點，比如串列埠的ttysx 才能正常啟動shell，完成以上指令碼的執行，那就要看具體情況了。

3 使用中的一些問題的思考

3.1 關於規則的多次匹配

幫助文件中說乙個裝置能夠被多條規則多次匹配，但是，需要明確的一點是：

多次匹配只能新增多個symlink，不能建立多個name：

例如：kernel=="mtdblock4", name+="mtdbb4"

kernel=="mtdblock4", name+="%k"

就只會建立 /dev/mtdbb4 而不會建立/dev/mtdblock4

而類似：

kernel=="mtdblock4", name+="mtdbb4"

kernel=="mtdblock4", symlink+="mtdbb4link"

是能夠正常工作的。

3.2 關於udev.conf的語法

可能大家會發現，似乎沒有什麼周詳文件描述udev.conf的寫法，實際上從udevd的**裡能夠看出：

udev.conf文件裡面只會解析這三個引數：

udev_root 定義udev的目錄路徑

udev_rules 定義udev的規則文件的目錄路徑

udev_log 定義log的級別

也許以後會新增一些別的配置引數？

4 基本工作原理方面的問題

這部分主要是分析了一下udev的source code，對一些自己關心的問題的理解

4.1 udevd如何獲取核心的這些模組動態變化的資訊

裝置節點的建立，是通過sysfs介面分析dev文件取得裝置節點號，這個很顯而易見。那麼udevd是通過什麼機制來得知核心裡模組的變化情況，如何得知裝置的插入移除情況呢？當然是通過hotplug機制了，那 hotplug又是怎麼實現的？或說核心是如何通知使用者空間乙個事件的發生的呢？

答案是通過netlink socket通訊，在核心和使用者空間之間傳遞資訊。

內核呼叫kobject_uevent函式傳送netlink message給使用者空間，這部分工作通常無需驅動去自己處理，在統一裝置模型裡面，在子系統這一層面，已將這部分**處理好了，包括在裝置對應的特定的 kobject建立和移除的時候都會傳送相應add和remove訊息，當然前提是您在核心中配置了hotplug的支援。

netlink socket作為一種核心和使用者空間的通訊方式，不但僅用在hotplug機制中，同樣還應用在其他很多真正和網路相關的核心子系統中。

udevd通過標準的socket機制，建立socket連線來獲取核心廣播的uevent事件並解析這些uevent事件。

4.2 udevd如何監控規則文件的變更

假如核心版本足夠新的話，在規則文件發生變化的時候，udev也能夠自動的重新應用這些規則，這得益於核心的inotify機制， inotify是一種文件系統的變化通知機制，如文件增加、刪除等事件能夠立即讓使用者態得知。

在udevd中，對inotify和udev的netlink socket文件描述符都進行了select的等待操作。有事件發生以後再進一步處理。

4.3 udevtrigger的工作機制？

執行udevd以後，使用udevtrigger的時候，會把核心中已存在的裝置的節點建立出來，那麼他是怎麼做到這一點的？分析udevtrigger的**能夠看出：

udevtrigger通過向/sysfs 文件系統下現有裝置的uevent節點寫"add"字串，從而觸發uevent事件，使得udevd能夠接收到這些事件，並建立buildin的裝置驅動的裝置節點連同任何已insmod的模組的裝置節點。

所以，我們也能夠手工用命令列來模擬這一過程：

/ # echo "add" > /sys/block/mtdblock2/uevent

/ #

/ # uevent[178.415520] add /block/mtdblock2 (block)

但是，進一步看**，您會發現，實際上，不管您往uevent裡面寫什麼，都會觸發add事件，這個從kernel內部對uevent屬性的實現函式能夠看出來，預設的實現是：

static ssize_t store_uevent(struct device *dev, struct device_attribute *attr,

const char *buf, size_t count)

所以不管寫的內容是什麼，都是觸發add操作，真遺憾，我還想通過這個屬性實驗remove的操作。不知道這樣限制的原因是什麼。

而udevstart的實現方式和udevtrigger就不同了，他基本上是重複實現了udevd裡面的機制，通過遍歷sysfs，自己完成裝置節點的建立，不通過udevd來完成。

4.4 其他

udevd建立每乙個節點的時候，都會fork出乙個新的程序來單獨完成這個節點的建立工作。

uevent_seqnum 用來標識當前的uevent事件的序號（已產生了多少uevent事件），您能夠通過如下操作來檢視：

$ cat /sys/kernel/uevent_seqnum

2673

Udev 基本工作原理

udev檔案系統的使用和基本工作原理分析

udev檔案系統的使用和基本工作原理分析

udev實現原理

Udev 基本工作原理

udev檔案系統的使用和基本工作原理分析

udev檔案系統的使用和基本工作原理分析

udev實現原理

相關推薦