Linux: udev 介紹

-

在談論udev之前,先要知道/dev這目錄. /dev在linux用途是存放device node(file-like device nodes). 程式可以透過device node來與系統上的裝置溝通.
e.g. /dev/input/mice 為滑鼠

那誰負責管理/dev底下的device node? 沒錯,那就是udev最主要的工作.
kernel會把裝置相關的events(add/remove/etc.)傳送至udev(藉由netlink). udev根據寫好的rules,在/dev底下建立對應的device node. 而這些rules會根據裝置的屬性去撰寫相關設定條件. 針對符合規則的裝置做對應的處理

到這時候應該會好奇要怎麼去得知道裝置的屬性呢? 而這邊就要談到 /sys (file type: sysfs), 這個是由kernel所維護的device資訊, kernel會把連接上的裝置資訊給放在這邊. udev在建立device node的時候也會參考這邊相關的屬性
e.g.
udevadm info -a --name /dev/input/mice
or
udevadm info -a --path $(udevadm info --query=path --name=/dev/input/mice)

接下來談的部分是udev rules. 基本上rule是由match keys和assignment keys這兩個部分構成.
match key主要是作為條件判斷用. assignment keys則是用來設定數值與執行相關操作. 每一條rule至少都要有一個 match key 和 assignment key. 在 rule 中的這些keys則使用逗號(,)來做隔離, 並不允許由多行的keys來成一條rule. 這意味著udev rule file中的每一行就是一條rule. 

KERNEL=="sda", ATTR{size}=="234441648", NAME="sda", SYMLINK+=disk/by-id/ata-VBOX_HARDDISK_VBa2440069-7fdbc2ad
這一個例子是判斷KERNEL是否符合sda和ATTR{size}是否符合對應大小. 條件成立就建立device node以及一個指向device node的soft link.

以下是另一個範例, 針對usb的裝置建立一個對應的symlink

KERNEL=="sd*", SUBSYSTEM=="block", ACTION=="add", SYMLINK+="test/usbhd%n"

這邊再額外補充rule的限制一下. 下方是經由udevadm指令抓出關於device的屬性. 而在參考attr撰寫規則有一點需要特別注意. 只允許混合device本身屬性和某一層parent的屬性而已. 也是只允許 '黑, 黑金 或 黑紅'' 的組合.


looking at device '.../target2:0:0/2:0:0:0/block/sda':
    KERNEL=="sda"
    SUBSYSTEM=="block"
    DRIVER==""
    ATTR{alignment_offset}=="0"
    ...
looking at parent device '.../target2:0:0/2:0:0:0':
    KERNELS=="2:0:0:0"
    SUBSYSTEMS=="scsi"
    DRIVERS=="sd"
    ATTRS{device_blocked}=="0"
    ...
looking at parent device '.../target2:0:0':
    KERNELS=="target2:0:0"
    SUBSYSTEMS=="scsi"
    DRIVERS==""

以下為match keys與assignment keys的列表

Key TypeKey Name
match keyKERNEL/SUBSYSTEM/DRIVER/ATTR{key}/ENV{key}/ACTION/TEST
assigment keyNAME/GROUP/MODE/OPTIONS/OWNER/OWN/RUN/SYMLINK/ENV{key}/IMPORT{type}/ATTR{key}/GOTO/LABEL/WAIT_FOR

Reference

  1. Writing udev rules
  2. Device Management
  3. Oracle® Linux Administrator's Guide for Release 6 : About Udev Rules

留言

張貼留言

這個網誌中的熱門文章

yocto recipe : (1) 撰寫 recipe

-
此篇文章介紹如何透過 yocto 的 utilities 來產生 recipe. 而完成的 recipe 又如何加入到 image. yocto 相關工具介紹 有三個適用於 layer 與 recipe 相關的 utilities. bitbake-layers: 負責 (1) 建立 layer. (2) 修改 bblayers.conf. (3) 查看 layer 底下的 recipes recipetool: 用於建立一個 recipe 和新增/修改 recipe. 這邊 recipe 在 yocto 即是 xx.bb 或 xx.bbappend 檔案 devtool: 定位在開發測試上. devtool 會建立一個獨立的 workspace layer. 讓開發者於此建立/修改 recipe 與 patch source code. 在不修改原有設定下與現有 layers 進行整合測試. 完畢之後可以再透過 devtool 新增或更新到 layer 裡 利用 utilities 撰寫 recipe 的時候. 要確保所屬的 layer 是存在於 bblayer.conf. 不然執行 bitbake [recipe basename] 會找不到相關的 recipe. yocto 事前準備 以 core-image-miniaml recipe 為例子. core-image-miniaml 會產生系統所需的 image 相關檔案. 接著利用 bitbake-layers 建立自己的 layer 於 build 目錄底下. 再透過 bitbake-layers 把 layer 加入到 bblayers.conf 設定檔. [ yijyun@localhost poky ] $ . oe-init-build-env [ yijyun@localhost build ] $ bitbake core-image-minimal [ yijyun@localhost build ] $ bitbake-layers create-layer meta-layer [ yijyun@localhost build ] $ bitbake-layers add-
閱讀完整內容

yocto recipe : (2) 撰寫 bbappend

-
前言 xxx.bb 檔案是用來描述一個 recipe. 然而 xxx.bb 會因為 patch codes、新增 tasks、等等的因素修改. 這邊介紹如何使用 xxx.bbappend[1] 檔案. 以不修改 xxx.bb 的情況下擴充需求. 文章將以 patch codes 為例子, 並個別以 devtool 工具和手動的方式示範. bbapend 簡介 .bbappend 是擴充 .bb 的方式. 藉由 .bbappend 來新增 tasks、patch code、新增/修改變數等等諸此之類的事. 其名稱必須跟所要修改的相同, 而版本號則依據需求寫. 舉例: bb file 名稱: giflib_5.1.4.bb bbappend 名稱: giflib_5.1.4.bbappend 或 giflib_%.bbappend. %: 表示萬用字元 使用 .bbappend 的情況, 我個人認為有以下情況再使用 (1) 當 recipe 已存在 yocto 最基本的 layer, 不應隨便修改. 舉例: u-boot_2017.09.bb 存在於 yocto 的 meta layer (2) 某些 layers 會共用此 recipe 的情況下. 舉例: meta-raspberrypi 與 meta-ti 分別各自使用自己的 xserver-xf86-config_0.1.bbappend 來對 yocto meta layer 的 xserver-xf86-config_0.1.bb 做擴充修改. bbappend 範例 事前準備 用 giflib [4] 作為測試程式. 先下載 giflib-5.1.4.tar.bz2. 接著使用 bitbake-layer 建立 meta-custom layer, 再透過 recipetool 把產生的 giflib_5.1.4.bb 存放於此 layer. # 執行 oe-init-build-env 進行 yocto 編譯環境設定 [ yijyun@localhost poky ] $ . oe-init-build-env # 建立 3rd-pkgs, 並把 giflib 放至此 [ yijyun@localhost build ] $
閱讀完整內容

yocto recipe : (3) 使用 External Source 來編譯軟體

-
Yocto 有提供許多 fetch code 的方式[3], 大都是以抓取外網的方式. 雖然很齊全, 但是開發時候多少需要以本機上的 source code 作為來源進行編譯. 這邊就紀錄如何讓 yocto 直接抓取本機上的 source code 使用本機上的 source code 這邊介紹兩種方式. 使用硬碟上的 source code, 而不是透過 yocto fetch 去網路上抓取 (1) git fetcher: 基於 git fetcher, 僅修改 src_uri 參數, 就可以用本機上的 source code (2) external source: 基於 externalsrc class. 有兩種方式達成: (1) 於 recipe 直接新增 external source 變數 (2)於 local.conf 新增特定 recipe 的 external source 參數. 事前準備 於 build 目錄底下建立 3rd-pkgs. 把下載的 giflib 程式碼放置於此 [ yijyun@localhost build ] $ pwd /media/disk1-1/Github/poky/build [ yijyun@localhost build ] $ ls 3rd-pkgs/ giflib-5.1.4.tar.bz2 新增 meta-test 於 yocto. 並在此 meta-layer 底下新增 giflib 目錄. 存放之後的 bb files [ yijyun@localhost build ] $ bitbake-layers create-layer meta-test [ yijyun@localhost build ] $ bitbake-layers add-layer meta-test [ yijyun@localhost build ] $ mkdir meta-test/recipes-example/giflib git fetcher 使用 git fetcher 有兩個重點: src_uri 的 protocol 參數需要改為 file. S 的路徑要改為 S="
閱讀完整內容