動實驗：設備號分配與cdev結構體全流程解析)
做 ARM Linux 驅(qū)動繞不開一個經(jīng)典實驗LED。這些年在網(wǎng)上能翻到的教程一大半還在用老版register_chrdevmknod那套寫法放到 Ubuntu20.04 的新內(nèi)核上要么編譯報錯要么加載后行為不對勁。標題里提到的“新版 LED 驅(qū)動實驗原理”和“設備號分配 cdev 結構體全流程”其實點出了新舊兩套框架最本質(zhì)的差異新版把一個黑盒拆成了幾個顯式步驟每一步都讓你自己控制、自己釋放。這篇文章就照著 Ubuntu20.04 環(huán)境把從設備號申請到 cdev 注冊、再到/dev/led節(jié)點自動出現(xiàn)的完整鏈路走一遍順帶把我在調(diào)試中踩過的坑填給你適合剛從 2.6/3.x 老代碼切過來、或者準備正經(jīng)寫字符設備驅(qū)動的開發(fā)者參考。1. 從“一鍵打包”到“全流程拆解”新版 LED 驅(qū)動實驗的框架差異1.1 老版 register_chrdev 到底封裝了什么早期驅(qū)動里最常見的一段代碼是這樣的ret register_chrdev(major, led, led_fops);如果major傳 0內(nèi)核會替你動態(tài)分配一個主設備號如果傳一個固定值那就把該主設備號占下來?？粗∈碌@個函數(shù)內(nèi)部做的事情遠比表面多它會申請一段設備號區(qū)間、初始化一個cdev結構體、把file_operations掛上去并且一下就占滿 256 個次設備號。問題也隨之而來。第一你無法精細管理次設備號比如一個驅(qū)動要控制 8 個 LED你想讓每個 LED 各占一個次設備號老接口根本表達不出這種意圖它默認把所有次設備號都包圓了。第二主設備號沖突極難排查內(nèi)核只在申請失敗時返回一個錯誤碼不會告訴你是誰占用了這個號你得自己去翻/proc/devices。第三也是最讓新手難受的一點設備節(jié)點不會自己出現(xiàn)。老教程會教你在加載后用mknod /dev/led c major 0手動建節(jié)點而現(xiàn)代發(fā)行版的/dev由 devtmpfs/udev 管理手動mknod出來的節(jié)點在系統(tǒng)重啟后就會消失權限也經(jīng)常不對。這并不是說register_chrdev不能用了它在 5.x 內(nèi)核里依然作為兼容接口存在但新代碼再走這條路等于放棄了內(nèi)核提供的大量資源管理能力。新版驅(qū)動把流程拆成我們下面要講的“設備號分配 → cdev 注冊 → 設備節(jié)點創(chuàng)建”三段讓每一步都可控、可回滾、可排查。1.2 新版全流程每個環(huán)節(jié)各管一攤新版 LED 驅(qū)動在module_init里要按順序做四件事分配設備號alloc_chrdev_region或register_chrdev_region初始化并添加cdevcdev_initcdev_add創(chuàng)建 classclass_create創(chuàng)建設備節(jié)點device_create。對應在module_exit里清理順序嚴格反著來先銷毀設備節(jié)點再銷毀 class然后移除 cdev最后釋放設備號。我經(jīng)常跟新人講這段順序不是隨便定的它對應的是資源依賴關系device_create依賴 class 存在cdev 依賴設備號存在所以你銷毀的時候必須從最上層開始一層層拆先斷掉用戶可見的入口再回收內(nèi)核資源。我用一個生活類比來理解這套模型設備號是房子的門牌號cdev是房子里擺好的辦公桌file_operations是桌上貼著的工作流程說明而/dev/led這個節(jié)點則是門口掛的招牌。沒有門牌號辦公桌不知道掛靠在哪沒有辦公桌客人來了沒人接待沒有招牌用戶根本不知道有這個房間。新版驅(qū)動把這三件事一步步做每一步失敗都能立刻定位到是哪塊出了問題。2. 設備號分配alloc_chrdev_region 和 register_chrdev_region 怎么選2.1 dev_t 與 MKDEV/MAJOR/MINOR 的編碼規(guī)則設備號在內(nèi)核里是一個dev_t類型本質(zhì)是個 32 位無符號整數(shù)。高 12 位是主設備號低 20 位是次設備號。主設備號用來區(qū)分設備類型和對應的驅(qū)動次設備號用來區(qū)分同一驅(qū)動下的多個實例。直接位運算容易出錯內(nèi)核提供了現(xiàn)成宏#include linux/kdev_t.h dev_t devno MKDEV(240, 0); // 主設備號 240次設備號 0 int major MAJOR(devno); // 取出主設備號 int minor MINOR(devno); // 取出次設備號主設備號在 5.x 內(nèi)核里可用于注冊的范圍大約到 511實際分配時建議別手寫固定值除非你有明確理由。次設備號的 20 位空間足夠讓一個主設備掛幾百萬個同類型設備所以驅(qū)動里通常一個主設備號配合多個次設備號使用。我在調(diào)試時候的習慣是先把MAJOR(devno)和MINOR(devno)打出來看確認設備號確實拿到了再進行下一步。這一步出錯后面所有工作都白做。2.2 兩種分配函數(shù)的適用場景設備號分配有兩個 API很多新手搞不清區(qū)別其實看名字就夠直白函數(shù)傳入?yún)?shù)特點適用場景風險register_chrdev_region(dev_t first, unsigned count, const char *name)需要手動構造first即指定起始設備號調(diào)試時固定設備號、產(chǎn)品有明確主設備號約定可能與其他驅(qū)動沖突加載失敗alloc_chrdev_region(dev_t *dev, unsigned firstminor, unsigned count, const char *name)內(nèi)核自動分配結果寫入指針產(chǎn)品代碼、避免手工管理設備號每次加載主設備號可能不同如果你想固定主設備號代碼這么寫static int major 240; dev_t devno; devno MKDEV(major, 0); ret register_chrdev_region(devno, 1, led); if (ret 0) { pr_err(failed to register chrdev region\n); return ret; }如果讓內(nèi)核動態(tài)分配dev_t devno; ret alloc_chrdev_region(devno, 0, 1, led); if (ret 0) { pr_err(failed to alloc chrdev region\n); return ret; } major MAJOR(devno); pr_info(led major %d, minor %d\n, major, MINOR(devno));我在實際項目里強烈推薦第二種原因很現(xiàn)實你永遠不知道目標板子上哪些主設備號已經(jīng)被其他驅(qū)動占了。動態(tài)分配把“找空號”這件事交給內(nèi)核沖突概率降到最低。調(diào)試階段為了復現(xiàn)問題可以加一個模塊參數(shù)允許手動指定主設備號0 表示動態(tài)分配。static int major 0; module_param(major, int, 0644); if (major) { devno MKDEV(major, 0); ret register_chrdev_region(devno, 1, led); } else { ret alloc_chrdev_region(devno, 0, 1, led); }這樣insmod led.ko默認動態(tài)分配insmod led.ko major241則固定為 241調(diào)試和產(chǎn)品兩不誤。2.3 設備號釋放與常見沖突排查設備號屬于內(nèi)核全局資源用完了必須還回去。釋放函數(shù)只有配套的unregister_chrdev_region(devno, count)一個放在module_exit的最后一步執(zhí)行。我在代碼審查時見過不少新手把unregister_chrdev_region放在cdev_del之前當時看不出問題但設備文件還開著的時候內(nèi)核按設備號找不到對應的cdev系統(tǒng)日志里就會冒出一些奇怪的錯誤。排查設備號沖突最直接的辦法是加載前先看一眼cat /proc/devices這個文件列出當前已經(jīng)注冊的字符設備和塊設備的設備號與名稱。如果發(fā)現(xiàn)目標主設備號已經(jīng)在列表里那就別硬搶。還有一招是用grep過濾cat /proc/devices | grep led如果日志出現(xiàn)register_chrdev_region: ... already in use之類的提示多半就是主設備號撞車了。3. cdev 結構體如何把 file_operations 掛到設備號上3.1 struct cdev 的關鍵成員與初始化設備號只是給設備發(fā)了一張“身份證”真正讓這張身份證生效的是cdev。內(nèi)核源碼里的定義大致如下struct cdev { struct kobject kobj; struct module *owner; const struct file_operations *ops; dev_t dev; unsigned int count; };四個關鍵成員各有用處kobj讓cdev成為內(nèi)核對象模型的一員可以被引用計數(shù)管理owner通常寫成THIS_MODULE保證設備正被使用時模塊不能被卸載ops掛載文件操作函數(shù)集是業(yè)務核心dev記錄它對應的設備號count表示占用了多少個次設備號。初始化有兩種方式。一種是在文件作用域直接放一個struct cdevstatic struct cdev led_cdev; cdev_init(led_cdev, led_fops);另一種先用cdev_alloc()動態(tài)分配再cdev_init()。對于 LED 這種單實例驅(qū)動我建議用靜態(tài)方式少一次動態(tài)內(nèi)存管理就少一類內(nèi)存泄漏隱患多實例場景再用動態(tài)方式按需創(chuàng)建。初始化完成后led_cdev.owner THIS_MODULE這行也別忘了否則模塊卸載時會出問題。3.2 cdev_add 的時機與錯誤處理cdev_add是真正把cdev和設備號綁進內(nèi)核的設備表里的動作ret cdev_add(led_cdev, devno, 1); if (ret 0) { pr_err(failed to add cdev\n); goto err_unregister; }第三個參數(shù)是設備數(shù)量一般寫 1如果申請了多個次設備號就寫對應的數(shù)量。這里特別提醒一個最容易忽視的點cdev_add一旦成功用戶空間立刻就能打開這個設備了所以在這之前必須保證后續(xù)所有資源都已經(jīng)準備好。順序反了比如先cdev_add再class_create那么成功添加后到 class 創(chuàng)建前這個短暫窗口內(nèi)已經(jīng)可以 open 設備但節(jié)點還不存在容易讓上層應用拿到一個半成品設備。cdev_add失敗時要記得把前面分配的設備號釋放掉。我最?？吹降膯栴}就是失敗分支里只return -EINVAL設備號還掛在系統(tǒng)里第二次加載直接撞車。正確的回滾順序是cdev_del→unregister_chrdev_region一層層退回去。3.3 file_operations 里怎么設計 LED 的操作入口file_operations是驅(qū)動與用戶空間交互的接口表。LED 實驗不需要復雜功能核心就三個open、write、release。以下是新內(nèi)核推薦的空 open 寫法static int led_open(struct inode *inode, struct file *filp) { return 0; }如果有多個 LED可以在open里通過iminor(inode)取出次設備號確定當前操作的是哪一路 LED。write里要接收用戶傳進來的“開/關”指令static ssize_t led_write(struct file *filp, const char __user *buf, size_t count, loff_t *ppos) { char value; if (copy_from_user(value, buf, 1)) return -EFAULT; if (value 1) led_set_state(1); else if (value 0) led_set_state(0); else return -EINVAL; return 1; }注意這里不能直接用*buf那是用戶空間地址內(nèi)核線程不能直接解引用。copy_from_user返回值為 0 表示拷貝成功返回值非 0 表示還有多少字節(jié)沒拷完應當返回-EFAULT。這個細節(jié)是新手最容易踩的不拷貝直接解引用輕則讀到垃圾值重則觸發(fā)內(nèi)核 oops。file_operations定義如下static const struct file_operations led_fops { .owner THIS_MODULE, .open led_open, .write led_write, .release led_release, };寫const是必須的因為內(nèi)核只允許注冊只讀的file_operations表。4. 設備節(jié)點從 mknod 到自動出現(xiàn)class_create 與 device_create 的配合4.1 /dev/led 這個節(jié)點到底是誰創(chuàng)建的老框架需要mknod手動創(chuàng)建節(jié)點但新版驅(qū)動在module_init里調(diào)用device_create后/dev/led會自動出現(xiàn)。這個“自動”的背后是 udev 在干活device_create會向內(nèi)核的 sysfs 寫入設備信息并觸發(fā) ueventudev 守護進程收到事件后根據(jù)設備所屬的 class 和名字在/dev下創(chuàng)建對應節(jié)點。對于嵌入式環(huán)境里不用 udev、而是用 busybox 的場景對應的機制是 mdev需要在啟動腳本里配置 mdev 的規(guī)則。Ubuntu20.04 桌面版和服務器版默認都有 udev所以我們在 PC 上跑模塊時基本上不需要額外配置。class_create的作用是給設備分組。設備創(chuàng)建后你會在/sys/class/led/下面看到這個設備這也是用戶態(tài)程序發(fā)現(xiàn)硬件設備的入口之一?？梢岳斫鉃閏lass是設備在 sysfs 里的“目錄名”決定它歸到哪個類目下面。4.2 device_create 參數(shù)逐項拆解device_create這個函數(shù)參數(shù)比較多我一個個解釋static struct class *led_class; static struct device *led_device; led_class class_create(THIS_MODULE, led); if (IS_ERR(led_class)) { pr_err(failed to create class\n); goto err_cdev_del; } led_device device_create(led_class, NULL, devno, NULL, led); if (IS_ERR(led_device)) { pr_err(failed to create device\n); goto err_class_destroy; }第一個參數(shù)led_class是設備歸屬的 class第二個參數(shù)parent通常傳 NULL第三個參數(shù)devno是這個設備對應的設備號它是設備和cdev掛鉤的錨點第四個參數(shù)drvdata可以傳驅(qū)動的私有數(shù)據(jù)指針LED 實驗里不需要最后一個變參是設備節(jié)點名字的格式化字符串比如想要led0、led1這種名字就寫成device_create(led_class, NULL, devno, NULL, led%d, 0)。要注意class_create和device_create的返回值都是錯誤指針。判斷時不能直接和 NULL 比較要用IS_ERR()和PTR_ERR()if (IS_ERR(led_device)) { ret PTR_ERR(led_device); goto err_class_destroy; }4.3 完整可編譯的 LED 驅(qū)動代碼把前三章的思路串起來就是一個完整的新版 LED 字符設備驅(qū)動。我貼一個能直接編譯的版本實際硬件控制部分我用一個接口函數(shù)代替你換成自己的 GPIO 或寄存器操作即可#include linux/module.h #include linux/kernel.h #include linux/fs.h #include linux/cdev.h #include linux/device.h #include linux/uaccess.h #define LED_DEV_COUNT 1 static int major 0; module_param(major, int, 0644); MODULE_PARM_DESC(major, led major number, 0 for dynamic alloc); static dev_t led_devno; static struct cdev led_cdev; static struct class *led_class; static struct device *led_device; static void led_set_state(int state) { /* 實際項目中替換為 ioremap 寄存器操作或 gpiod_set_value */ pr_info(led state - %d\n, state); } static ssize_t led_write(struct file *filp, const char __user *buf, size_t count, loff_t *ppos) { char value; if (count 1) return -EINVAL; if (copy_from_user(value, buf, 1)) return -EFAULT; if (value 1) led_set_state(1); else if (value 0) led_set_state(0); else return -EINVAL; return 1; } static int led_open(struct inode *inode, struct file *filp) { return 0; } static int led_release(struct inode *inode, struct file *filp) { return 0; } static const struct file_operations led_fops { .owner THIS_MODULE, .open led_open, .write led_write, .release led_release, }; static int __init led_init(void) { int ret; if (major) { led_devno MKDEV(major, 0); ret register_chrdev_region(led_devno, LED_DEV_COUNT, led); } else { ret alloc_chrdev_region(led_devno, 0, LED_DEV_COUNT, led); } if (ret 0) { pr_err(failed to alloc/register chrdev region\n); return ret; } major MAJOR(led_devno); pr_info(led major %d, minor %d\n, major, MINOR(led_devno)); cdev_init(led_cdev, led_fops); led_cdev.owner THIS_MODULE; ret cdev_add(led_cdev, led_devno, LED_DEV_COUNT); if (ret 0) { pr_err(failed to add cdev\n); goto err_unregister_region; } led_class class_create(THIS_MODULE, led); if (IS_ERR(led_class)) { ret PTR_ERR(led_class); pr_err(failed to create class\n); goto err_cdev_del; } led_device device_create(led_class, NULL, led_devno, NULL, led); if (IS_ERR(led_device)) { ret PTR_ERR(led_device); pr_err(failed to create device\n); goto err_class_destroy; } return 0; err_class_destroy: class_destroy(led_class); err_cdev_del: cdev_del(led_cdev); err_unregister_region: unregister_chrdev_region(led_devno, LED_DEV_COUNT); return ret; } static void __exit led_exit(void) { device_destroy(led_class, led_devno); class_destroy(led_class); cdev_del(led_cdev); unregister_chrdev_region(led_devno, LED_DEV_COUNT); pr_info(led driver removed\n); } module_init(led_init); module_exit(led_exit); MODULE_LICENSE(GPL); MODULE_AUTHOR(A Developer); MODULE_DESCRIPTION(New style LED char device driver); MODULE_VERSION(1.0);這個文件保存為led.c和后面的 Makefile 放同一目錄。加載后write一個1或0進去日志里會打印led state - 1或led state - 0。換成真實硬件時只要把led_set_state里的占位代碼替換成實際的點燈/滅燈操作即可字符設備那套框架完全不用動。5. Ubuntu20.04 上編譯模塊KDIR 與 Makefile 是關鍵5.1 本機編譯與交叉編譯的取舍Ubuntu20.04 在驅(qū)動開發(fā)里通常有兩個角色。如果你只是想在 x86 主機上驗證字符設備框架直接用本機內(nèi)核頭文件編譯模塊insmod到當前系統(tǒng)就能測。如果你手上有 ARM 開發(fā)板需要把 Ubuntu 當作宿主機給目標板交叉編譯.ko文件。本機編譯需要安裝內(nèi)核頭文件最簡單的方式sudo apt update sudo apt install linux-headers-generic裝完后一般指向/lib/modules/$(uname -r)/build目錄。uname -r查看當前內(nèi)核版本如果頭文件版本和當前運行內(nèi)核不一致編譯時 vermagic 對不上insmod時會拒絕加載。這一點在升級內(nèi)核后特別容易踩舊頭文件還在但當前內(nèi)核已經(jīng)換新版本了。交叉編譯則要準備目標板同版本的內(nèi)核源碼并且該源碼目錄已經(jīng)完成配置。這個源碼目錄就是 KDIR編譯出的模塊和開發(fā)板內(nèi)核的 vermagic 必須完全一致否則加載時報version magic不匹配。所以內(nèi)核源碼版本要和開發(fā)板燒錄的內(nèi)核版本嚴格對應最好直接用制作內(nèi)核鏡像時的那份源碼。5.2 Makefile 模板外部模塊的 Makefile 是一個固定套路核心是調(diào)用內(nèi)核構建系統(tǒng)obj-m : led.o KERNELDIR ? /lib/modules/$(shell uname -r)/build PWD : $(shell pwd) all: $(MAKE) -C $(KERNELDIR) M$(PWD) modules clean: $(MAKE) -C $(KERNELDIR) M$(PWD) clean-C告訴 make 先切換到內(nèi)核構建目錄M$(PWD)指回模塊源碼目錄modules是構建目標。這個 Makefile 里的縮進必須是 Tab不能用空格否則 make 直接報錯我見過太多次因為這個原因卡住的情況。交叉編譯時改成ARCH ? arm CROSS_COMPILE ? arm-linux-gnueabihf- KERNELDIR ? /path/to/kernel/source all: $(MAKE) -C $(KERNELDIR) M$(PWD) ARCH$(ARCH) CROSS_COMPILE$(CROSS_COMPILE) modules clean: $(MAKE) -C $(KERNELDIR) M$(PWD) ARCH$(ARCH) CROSS_COMPILE$(CROSS_COMPILE) cleanCROSS_COMPILE是工具鏈前綴Ubuntu20.04 上安裝 32 位 ARM 工具鏈sudo apt install gcc-arm-linux-gnueabihf安裝完確認一下arm-linux-gnueabihf-gcc -v工具鏈能跑起來再繼續(xù)否則后面所有交叉編譯命令都會以command not found告終。5.3 編譯報錯與模塊加載校驗編譯階段最常出現(xiàn)的問題之一是頭文件找不到報錯類似linux/module.h: No such file or directory。這通常意味著KERNELDIR指向的目錄缺少include/generated或include/linux文件簡單說就是內(nèi)核頭文件沒準備好。解決方法是要么用發(fā)行版提供的linux-headers-generic要么在內(nèi)核源碼根目錄先執(zhí)行make prepare等配置步驟不能拿一個剛解壓的裸源碼目錄直接當 KDIR 用。另一個問題是架構混亂。如果你在一臺 x86 主機上編譯出了 ARM 的.ko可以先用file命令確認file led.ko輸出里能看到 ELF 架構信息比如ARM或x86-64。如果架構不對多半是 Makefile 里的ARCH和CROSS_COMPILE沒起作用或者上一次編譯的中間文件殘留。換架構之前先make clean清掉舊文件再編避免殘留的.o被復用。模塊編譯出來之后用modinfo看 vermagicmodinfo led.ko | grep vermagic這份信息和開發(fā)板內(nèi)核要一致。Ubuntu 桌面版默認開啟了安全啟動直接insmod可能報Required key not available那是模塊簽名校驗沒通過。臨時測試可以進入 BIOS 關閉 Secure Boot或者給模塊做簽名這個環(huán)節(jié)不是驅(qū)動邏輯問題但很容易卡住新手。6. 加載、測試、排錯實際跑一次新版 LED 驅(qū)動6.1 insmod 之后應該看到什么先把 Ubuntu20.04 上本機測試的完整流程走一遍。編譯成功得到led.ko然后用sudo加載sudo insmod led.ko緊接著觀察內(nèi)核日志dmesg | tail正常情況下應該能看到led major 240, minor 0數(shù)字取決于動態(tài)分配結果。然后確認設備號確實進入內(nèi)核cat /proc/devices | grep led再查看設備節(jié)點ls -l /dev/led如果有crw-rw---- 1 root root 240, 0 ... /dev/led說明整套鏈路已經(jīng)通了。此時用一個普通用戶訪問可能沒有權限測試時直接換成 root 或用sudoecho 1 /dev/led echo 0 /dev/led每執(zhí)行一次dmesg里應該多一行l(wèi)ed state - 1或led state - 0。如果你在板子上接了真實 LED這時候燈就會跟著亮滅。6.2 失敗鏈路排查清單我在帶人做實驗時總結過一套排查順序按現(xiàn)象定位最快現(xiàn)象可能原因排查與解決insmod 成功但 /dev/led 不存在device_create失敗或者 udev 沒有收到事件dmesg看是否有failed to create device檢查 class_create 是否成功/dev/led 存在但 open 失敗設備節(jié)點權限不足或 cdev_add 順序有問題sudo chmod 666 /dev/led臨時測試寫 udev 規(guī)則做永久處理open 成功但 echo 報錯copy_from_user失敗或 write 邏輯返回負數(shù)回到驅(qū)動代碼檢查 fops 里 write 是否注冊成功rmmod 報仍在占用有進程打開著 /dev/ledfuser -v /dev/led查看占用進程關閉后再卸載加載時設備號沖突register_chrdev_region 指定的 major 被占用cat /proc/devices查詢改用動態(tài)分配或換號特別說一下/dev/led權限問題。device_create創(chuàng)建的節(jié)點默認屬主是 root權限是 0600所以普通用戶echo進去必然被拒。臨時測試用chmod 666沒問題產(chǎn)品上建議寫一個 udev 規(guī)則按 class 和 subsystem 給設備節(jié)點設置權限組這樣每次開機自動生效不依賴手動改權限。6.3 動態(tài)主設備號對應用透明嗎這是許多新手最后會糾結的問題如果每次加載主設備號都變那我應用程序里寫死的mknod或者open路徑怎么辦答案是不用擔心。/dev/led這個節(jié)點名是device_create最后一個參數(shù)決定的和主設備號無關。應用層打開設備用的是路徑名真正打開時 VFS 會根據(jù)節(jié)點記錄的dev_t找到對應的cdev所以你完全不感知主設備號是多少。這也正是新版框架的價值設備號是內(nèi)核內(nèi)部資源應用只看到設備節(jié)點名。多 LED 場景就更好理解了。申請兩個次設備號device_create分別創(chuàng)建led0和led1應用行為完全一致驅(qū)動內(nèi)部通過iminor(inode)區(qū)分控制哪一路。LED 實驗跑通后建議你再補一個read方法和ioctl把整個字符設備驅(qū)動的骨架填滿后面寫按鍵、寫傳感器驅(qū)動時這套框架能直接復刻。最后提醒一句經(jīng)驗調(diào)試階段固定major241方便看現(xiàn)象但產(chǎn)品代碼里一定要默認走動態(tài)分配。我見過不止一次同事把測試時的固定設備號帶進量產(chǎn)程序結果目標板上那個號早被別的驅(qū)動占走驅(qū)動加載直接失敗排查大半天才反應過來。新版這套流程看著比老版多一些代碼但每一步都可控、可回滾、可定位等你能不看模板把這個鏈路默寫出來字符設備驅(qū)動基本上就入門了。 新版Linux LED驅(qū)動實驗：設備號分配與cdev結構體全流程解析
做 ARM Linux 驅(qū)動繞不開一個經(jīng)典實驗LED。這些年在網(wǎng)上能翻到的教程一大半還在用老版register_chrdevmknod那套寫法放到 Ubuntu20.04 的新內(nèi)核上要么編譯報錯要么加載后行為不對勁。標題里提到的“新版 LED 驅(qū)動實驗原理”和“設備號分配 cdev 結構體全流程”其實點出了新舊兩套框架最本質(zhì)的差異新版把一個黑盒拆成了幾個顯式步驟每一步都讓你自己控制、自己釋放。這篇文章就照著 Ubuntu20.04 環(huán)境把從設備號申請到 cdev 注冊、再到/dev/led節(jié)點自動出現(xiàn)的完整鏈路走一遍順帶把我在調(diào)試中踩過的坑填給你適合剛從 2.6/3.x 老代碼切過來、或者準備正經(jīng)寫字符設備驅(qū)動的開發(fā)者參考。1. 從“一鍵打包”到“全流程拆解”新版 LED 驅(qū)動實驗的框架差異1.1 老版 register_chrdev 到底封裝了什么早期驅(qū)動里最常見的一段代碼是這樣的ret register_chrdev(major, led, led_fops);如果major傳 0內(nèi)核會替你動態(tài)分配一個主設備號如果傳一個固定值那就把該主設備號占下來?？粗∈碌@個函數(shù)內(nèi)部做的事情遠比表面多它會申請一段設備號區(qū)間、初始化一個cdev結構體、把file_operations掛上去并且一下就占滿 256 個次設備號。問題也隨之而來。第一你無法精細管理次設備號比如一個驅(qū)動要控制 8 個 LED你想讓每個 LED 各占一個次設備號老接口根本表達不出這種意圖它默認把所有次設備號都包圓了。第二主設備號沖突極難排查內(nèi)核只在申請失敗時返回一個錯誤碼不會告訴你是誰占用了這個號你得自己去翻/proc/devices。第三也是最讓新手難受的一點設備節(jié)點不會自己出現(xiàn)。老教程會教你在加載后用mknod /dev/led c major 0手動建節(jié)點而現(xiàn)代發(fā)行版的/dev由 devtmpfs/udev 管理手動mknod出來的節(jié)點在系統(tǒng)重啟后就會消失權限也經(jīng)常不對。這并不是說register_chrdev不能用了它在 5.x 內(nèi)核里依然作為兼容接口存在但新代碼再走這條路等于放棄了內(nèi)核提供的大量資源管理能力。新版驅(qū)動把流程拆成我們下面要講的“設備號分配 → cdev 注冊 → 設備節(jié)點創(chuàng)建”三段讓每一步都可控、可回滾、可排查。1.2 新版全流程每個環(huán)節(jié)各管一攤新版 LED 驅(qū)動在module_init里要按順序做四件事分配設備號alloc_chrdev_region或register_chrdev_region初始化并添加cdevcdev_initcdev_add創(chuàng)建 classclass_create創(chuàng)建設備節(jié)點device_create。對應在module_exit里清理順序嚴格反著來先銷毀設備節(jié)點再銷毀 class然后移除 cdev最后釋放設備號。我經(jīng)常跟新人講這段順序不是隨便定的它對應的是資源依賴關系device_create依賴 class 存在cdev 依賴設備號存在所以你銷毀的時候必須從最上層開始一層層拆先斷掉用戶可見的入口再回收內(nèi)核資源。我用一個生活類比來理解這套模型設備號是房子的門牌號cdev是房子里擺好的辦公桌file_operations是桌上貼著的工作流程說明而/dev/led這個節(jié)點則是門口掛的招牌。沒有門牌號辦公桌不知道掛靠在哪沒有辦公桌客人來了沒人接待沒有招牌用戶根本不知道有這個房間。新版驅(qū)動把這三件事一步步做每一步失敗都能立刻定位到是哪塊出了問題。2. 設備號分配alloc_chrdev_region 和 register_chrdev_region 怎么選2.1 dev_t 與 MKDEV/MAJOR/MINOR 的編碼規(guī)則設備號在內(nèi)核里是一個dev_t類型本質(zhì)是個 32 位無符號整數(shù)。高 12 位是主設備號低 20 位是次設備號。主設備號用來區(qū)分設備類型和對應的驅(qū)動次設備號用來區(qū)分同一驅(qū)動下的多個實例。直接位運算容易出錯內(nèi)核提供了現(xiàn)成宏#include linux/kdev_t.h dev_t devno MKDEV(240, 0); // 主設備號 240次設備號 0 int major MAJOR(devno); // 取出主設備號 int minor MINOR(devno); // 取出次設備號主設備號在 5.x 內(nèi)核里可用于注冊的范圍大約到 511實際分配時建議別手寫固定值除非你有明確理由。次設備號的 20 位空間足夠讓一個主設備掛幾百萬個同類型設備所以驅(qū)動里通常一個主設備號配合多個次設備號使用。我在調(diào)試時候的習慣是先把MAJOR(devno)和MINOR(devno)打出來看確認設備號確實拿到了再進行下一步。這一步出錯后面所有工作都白做。2.2 兩種分配函數(shù)的適用場景設備號分配有兩個 API很多新手搞不清區(qū)別其實看名字就夠直白函數(shù)傳入?yún)?shù)特點適用場景風險register_chrdev_region(dev_t first, unsigned count, const char *name)需要手動構造first即指定起始設備號調(diào)試時固定設備號、產(chǎn)品有明確主設備號約定可能與其他驅(qū)動沖突加載失敗alloc_chrdev_region(dev_t *dev, unsigned firstminor, unsigned count, const char *name)內(nèi)核自動分配結果寫入指針產(chǎn)品代碼、避免手工管理設備號每次加載主設備號可能不同如果你想固定主設備號代碼這么寫static int major 240; dev_t devno; devno MKDEV(major, 0); ret register_chrdev_region(devno, 1, led); if (ret 0) { pr_err(failed to register chrdev region\n); return ret; }如果讓內(nèi)核動態(tài)分配dev_t devno; ret alloc_chrdev_region(devno, 0, 1, led); if (ret 0) { pr_err(failed to alloc chrdev region\n); return ret; } major MAJOR(devno); pr_info(led major %d, minor %d\n, major, MINOR(devno));我在實際項目里強烈推薦第二種原因很現(xiàn)實你永遠不知道目標板子上哪些主設備號已經(jīng)被其他驅(qū)動占了。動態(tài)分配把“找空號”這件事交給內(nèi)核沖突概率降到最低。調(diào)試階段為了復現(xiàn)問題可以加一個模塊參數(shù)允許手動指定主設備號0 表示動態(tài)分配。static int major 0; module_param(major, int, 0644); if (major) { devno MKDEV(major, 0); ret register_chrdev_region(devno, 1, led); } else { ret alloc_chrdev_region(devno, 0, 1, led); }這樣insmod led.ko默認動態(tài)分配insmod led.ko major241則固定為 241調(diào)試和產(chǎn)品兩不誤。2.3 設備號釋放與常見沖突排查設備號屬于內(nèi)核全局資源用完了必須還回去。釋放函數(shù)只有配套的unregister_chrdev_region(devno, count)一個放在module_exit的最后一步執(zhí)行。我在代碼審查時見過不少新手把unregister_chrdev_region放在cdev_del之前當時看不出問題但設備文件還開著的時候內(nèi)核按設備號找不到對應的cdev系統(tǒng)日志里就會冒出一些奇怪的錯誤。排查設備號沖突最直接的辦法是加載前先看一眼cat /proc/devices這個文件列出當前已經(jīng)注冊的字符設備和塊設備的設備號與名稱。如果發(fā)現(xiàn)目標主設備號已經(jīng)在列表里那就別硬搶。還有一招是用grep過濾cat /proc/devices | grep led如果日志出現(xiàn)register_chrdev_region: ... already in use之類的提示多半就是主設備號撞車了。3. cdev 結構體如何把 file_operations 掛到設備號上3.1 struct cdev 的關鍵成員與初始化設備號只是給設備發(fā)了一張“身份證”真正讓這張身份證生效的是cdev。內(nèi)核源碼里的定義大致如下struct cdev { struct kobject kobj; struct module *owner; const struct file_operations *ops; dev_t dev; unsigned int count; };四個關鍵成員各有用處kobj讓cdev成為內(nèi)核對象模型的一員可以被引用計數(shù)管理owner通常寫成THIS_MODULE保證設備正被使用時模塊不能被卸載ops掛載文件操作函數(shù)集是業(yè)務核心dev記錄它對應的設備號count表示占用了多少個次設備號。初始化有兩種方式。一種是在文件作用域直接放一個struct cdevstatic struct cdev led_cdev; cdev_init(led_cdev, led_fops);另一種先用cdev_alloc()動態(tài)分配再cdev_init()。對于 LED 這種單實例驅(qū)動我建議用靜態(tài)方式少一次動態(tài)內(nèi)存管理就少一類內(nèi)存泄漏隱患多實例場景再用動態(tài)方式按需創(chuàng)建。初始化完成后led_cdev.owner THIS_MODULE這行也別忘了否則模塊卸載時會出問題。3.2 cdev_add 的時機與錯誤處理cdev_add是真正把cdev和設備號綁進內(nèi)核的設備表里的動作ret cdev_add(led_cdev, devno, 1); if (ret 0) { pr_err(failed to add cdev\n); goto err_unregister; }第三個參數(shù)是設備數(shù)量一般寫 1如果申請了多個次設備號就寫對應的數(shù)量。這里特別提醒一個最容易忽視的點cdev_add一旦成功用戶空間立刻就能打開這個設備了所以在這之前必須保證后續(xù)所有資源都已經(jīng)準備好。順序反了比如先cdev_add再class_create那么成功添加后到 class 創(chuàng)建前這個短暫窗口內(nèi)已經(jīng)可以 open 設備但節(jié)點還不存在容易讓上層應用拿到一個半成品設備。cdev_add失敗時要記得把前面分配的設備號釋放掉。我最?？吹降膯栴}就是失敗分支里只return -EINVAL設備號還掛在系統(tǒng)里第二次加載直接撞車。正確的回滾順序是cdev_del→unregister_chrdev_region一層層退回去。3.3 file_operations 里怎么設計 LED 的操作入口file_operations是驅(qū)動與用戶空間交互的接口表。LED 實驗不需要復雜功能核心就三個open、write、release。以下是新內(nèi)核推薦的空 open 寫法static int led_open(struct inode *inode, struct file *filp) { return 0; }如果有多個 LED可以在open里通過iminor(inode)取出次設備號確定當前操作的是哪一路 LED。write里要接收用戶傳進來的“開/關”指令static ssize_t led_write(struct file *filp, const char __user *buf, size_t count, loff_t *ppos) { char value; if (copy_from_user(value, buf, 1)) return -EFAULT; if (value 1) led_set_state(1); else if (value 0) led_set_state(0); else return -EINVAL; return 1; }注意這里不能直接用*buf那是用戶空間地址內(nèi)核線程不能直接解引用。copy_from_user返回值為 0 表示拷貝成功返回值非 0 表示還有多少字節(jié)沒拷完應當返回-EFAULT。這個細節(jié)是新手最容易踩的不拷貝直接解引用輕則讀到垃圾值重則觸發(fā)內(nèi)核 oops。file_operations定義如下static const struct file_operations led_fops { .owner THIS_MODULE, .open led_open, .write led_write, .release led_release, };寫const是必須的因為內(nèi)核只允許注冊只讀的file_operations表。4. 設備節(jié)點從 mknod 到自動出現(xiàn)class_create 與 device_create 的配合4.1 /dev/led 這個節(jié)點到底是誰創(chuàng)建的老框架需要mknod手動創(chuàng)建節(jié)點但新版驅(qū)動在module_init里調(diào)用device_create后/dev/led會自動出現(xiàn)。這個“自動”的背后是 udev 在干活device_create會向內(nèi)核的 sysfs 寫入設備信息并觸發(fā) ueventudev 守護進程收到事件后根據(jù)設備所屬的 class 和名字在/dev下創(chuàng)建對應節(jié)點。對于嵌入式環(huán)境里不用 udev、而是用 busybox 的場景對應的機制是 mdev需要在啟動腳本里配置 mdev 的規(guī)則。Ubuntu20.04 桌面版和服務器版默認都有 udev所以我們在 PC 上跑模塊時基本上不需要額外配置。class_create的作用是給設備分組。設備創(chuàng)建后你會在/sys/class/led/下面看到這個設備這也是用戶態(tài)程序發(fā)現(xiàn)硬件設備的入口之一?？梢岳斫鉃閏lass是設備在 sysfs 里的“目錄名”決定它歸到哪個類目下面。4.2 device_create 參數(shù)逐項拆解device_create這個函數(shù)參數(shù)比較多我一個個解釋static struct class *led_class; static struct device *led_device; led_class class_create(THIS_MODULE, led); if (IS_ERR(led_class)) { pr_err(failed to create class\n); goto err_cdev_del; } led_device device_create(led_class, NULL, devno, NULL, led); if (IS_ERR(led_device)) { pr_err(failed to create device\n); goto err_class_destroy; }第一個參數(shù)led_class是設備歸屬的 class第二個參數(shù)parent通常傳 NULL第三個參數(shù)devno是這個設備對應的設備號它是設備和cdev掛鉤的錨點第四個參數(shù)drvdata可以傳驅(qū)動的私有數(shù)據(jù)指針LED 實驗里不需要最后一個變參是設備節(jié)點名字的格式化字符串比如想要led0、led1這種名字就寫成device_create(led_class, NULL, devno, NULL, led%d, 0)。要注意class_create和device_create的返回值都是錯誤指針。判斷時不能直接和 NULL 比較要用IS_ERR()和PTR_ERR()if (IS_ERR(led_device)) { ret PTR_ERR(led_device); goto err_class_destroy; }4.3 完整可編譯的 LED 驅(qū)動代碼把前三章的思路串起來就是一個完整的新版 LED 字符設備驅(qū)動。我貼一個能直接編譯的版本實際硬件控制部分我用一個接口函數(shù)代替你換成自己的 GPIO 或寄存器操作即可#include linux/module.h #include linux/kernel.h #include linux/fs.h #include linux/cdev.h #include linux/device.h #include linux/uaccess.h #define LED_DEV_COUNT 1 static int major 0; module_param(major, int, 0644); MODULE_PARM_DESC(major, led major number, 0 for dynamic alloc); static dev_t led_devno; static struct cdev led_cdev; static struct class *led_class; static struct device *led_device; static void led_set_state(int state) { /* 實際項目中替換為 ioremap 寄存器操作或 gpiod_set_value */ pr_info(led state - %d\n, state); } static ssize_t led_write(struct file *filp, const char __user *buf, size_t count, loff_t *ppos) { char value; if (count 1) return -EINVAL; if (copy_from_user(value, buf, 1)) return -EFAULT; if (value 1) led_set_state(1); else if (value 0) led_set_state(0); else return -EINVAL; return 1; } static int led_open(struct inode *inode, struct file *filp) { return 0; } static int led_release(struct inode *inode, struct file *filp) { return 0; } static const struct file_operations led_fops { .owner THIS_MODULE, .open led_open, .write led_write, .release led_release, }; static int __init led_init(void) { int ret; if (major) { led_devno MKDEV(major, 0); ret register_chrdev_region(led_devno, LED_DEV_COUNT, led); } else { ret alloc_chrdev_region(led_devno, 0, LED_DEV_COUNT, led); } if (ret 0) { pr_err(failed to alloc/register chrdev region\n); return ret; } major MAJOR(led_devno); pr_info(led major %d, minor %d\n, major, MINOR(led_devno)); cdev_init(led_cdev, led_fops); led_cdev.owner THIS_MODULE; ret cdev_add(led_cdev, led_devno, LED_DEV_COUNT); if (ret 0) { pr_err(failed to add cdev\n); goto err_unregister_region; } led_class class_create(THIS_MODULE, led); if (IS_ERR(led_class)) { ret PTR_ERR(led_class); pr_err(failed to create class\n); goto err_cdev_del; } led_device device_create(led_class, NULL, led_devno, NULL, led); if (IS_ERR(led_device)) { ret PTR_ERR(led_device); pr_err(failed to create device\n); goto err_class_destroy; } return 0; err_class_destroy: class_destroy(led_class); err_cdev_del: cdev_del(led_cdev); err_unregister_region: unregister_chrdev_region(led_devno, LED_DEV_COUNT); return ret; } static void __exit led_exit(void) { device_destroy(led_class, led_devno); class_destroy(led_class); cdev_del(led_cdev); unregister_chrdev_region(led_devno, LED_DEV_COUNT); pr_info(led driver removed\n); } module_init(led_init); module_exit(led_exit); MODULE_LICENSE(GPL); MODULE_AUTHOR(A Developer); MODULE_DESCRIPTION(New style LED char device driver); MODULE_VERSION(1.0);這個文件保存為led.c和后面的 Makefile 放同一目錄。加載后write一個1或0進去日志里會打印led state - 1或led state - 0。換成真實硬件時只要把led_set_state里的占位代碼替換成實際的點燈/滅燈操作即可字符設備那套框架完全不用動。5. Ubuntu20.04 上編譯模塊KDIR 與 Makefile 是關鍵5.1 本機編譯與交叉編譯的取舍Ubuntu20.04 在驅(qū)動開發(fā)里通常有兩個角色。如果你只是想在 x86 主機上驗證字符設備框架直接用本機內(nèi)核頭文件編譯模塊insmod到當前系統(tǒng)就能測。如果你手上有 ARM 開發(fā)板需要把 Ubuntu 當作宿主機給目標板交叉編譯.ko文件。本機編譯需要安裝內(nèi)核頭文件最簡單的方式sudo apt update sudo apt install linux-headers-generic裝完后一般指向/lib/modules/$(uname -r)/build目錄。uname -r查看當前內(nèi)核版本如果頭文件版本和當前運行內(nèi)核不一致編譯時 vermagic 對不上insmod時會拒絕加載。這一點在升級內(nèi)核后特別容易踩舊頭文件還在但當前內(nèi)核已經(jīng)換新版本了。交叉編譯則要準備目標板同版本的內(nèi)核源碼并且該源碼目錄已經(jīng)完成配置。這個源碼目錄就是 KDIR編譯出的模塊和開發(fā)板內(nèi)核的 vermagic 必須完全一致否則加載時報version magic不匹配。所以內(nèi)核源碼版本要和開發(fā)板燒錄的內(nèi)核版本嚴格對應最好直接用制作內(nèi)核鏡像時的那份源碼。5.2 Makefile 模板外部模塊的 Makefile 是一個固定套路核心是調(diào)用內(nèi)核構建系統(tǒng)obj-m : led.o KERNELDIR ? /lib/modules/$(shell uname -r)/build PWD : $(shell pwd) all: $(MAKE) -C $(KERNELDIR) M$(PWD) modules clean: $(MAKE) -C $(KERNELDIR) M$(PWD) clean-C告訴 make 先切換到內(nèi)核構建目錄M$(PWD)指回模塊源碼目錄modules是構建目標。這個 Makefile 里的縮進必須是 Tab不能用空格否則 make 直接報錯我見過太多次因為這個原因卡住的情況。交叉編譯時改成ARCH ? arm CROSS_COMPILE ? arm-linux-gnueabihf- KERNELDIR ? /path/to/kernel/source all: $(MAKE) -C $(KERNELDIR) M$(PWD) ARCH$(ARCH) CROSS_COMPILE$(CROSS_COMPILE) modules clean: $(MAKE) -C $(KERNELDIR) M$(PWD) ARCH$(ARCH) CROSS_COMPILE$(CROSS_COMPILE) cleanCROSS_COMPILE是工具鏈前綴Ubuntu20.04 上安裝 32 位 ARM 工具鏈sudo apt install gcc-arm-linux-gnueabihf安裝完確認一下arm-linux-gnueabihf-gcc -v工具鏈能跑起來再繼續(xù)否則后面所有交叉編譯命令都會以command not found告終。5.3 編譯報錯與模塊加載校驗編譯階段最常出現(xiàn)的問題之一是頭文件找不到報錯類似linux/module.h: No such file or directory。這通常意味著KERNELDIR指向的目錄缺少include/generated或include/linux文件簡單說就是內(nèi)核頭文件沒準備好。解決方法是要么用發(fā)行版提供的linux-headers-generic要么在內(nèi)核源碼根目錄先執(zhí)行make prepare等配置步驟不能拿一個剛解壓的裸源碼目錄直接當 KDIR 用。另一個問題是架構混亂。如果你在一臺 x86 主機上編譯出了 ARM 的.ko可以先用file命令確認file led.ko輸出里能看到 ELF 架構信息比如ARM或x86-64。如果架構不對多半是 Makefile 里的ARCH和CROSS_COMPILE沒起作用或者上一次編譯的中間文件殘留。換架構之前先make clean清掉舊文件再編避免殘留的.o被復用。模塊編譯出來之后用modinfo看 vermagicmodinfo led.ko | grep vermagic這份信息和開發(fā)板內(nèi)核要一致。Ubuntu 桌面版默認開啟了安全啟動直接insmod可能報Required key not available那是模塊簽名校驗沒通過。臨時測試可以進入 BIOS 關閉 Secure Boot或者給模塊做簽名這個環(huán)節(jié)不是驅(qū)動邏輯問題但很容易卡住新手。6. 加載、測試、排錯實際跑一次新版 LED 驅(qū)動6.1 insmod 之后應該看到什么先把 Ubuntu20.04 上本機測試的完整流程走一遍。編譯成功得到led.ko然后用sudo加載sudo insmod led.ko緊接著觀察內(nèi)核日志dmesg | tail正常情況下應該能看到led major 240, minor 0數(shù)字取決于動態(tài)分配結果。然后確認設備號確實進入內(nèi)核cat /proc/devices | grep led再查看設備節(jié)點ls -l /dev/led如果有crw-rw---- 1 root root 240, 0 ... /dev/led說明整套鏈路已經(jīng)通了。此時用一個普通用戶訪問可能沒有權限測試時直接換成 root 或用sudoecho 1 /dev/led echo 0 /dev/led每執(zhí)行一次dmesg里應該多一行l(wèi)ed state - 1或led state - 0。如果你在板子上接了真實 LED這時候燈就會跟著亮滅。6.2 失敗鏈路排查清單我在帶人做實驗時總結過一套排查順序按現(xiàn)象定位最快現(xiàn)象可能原因排查與解決insmod 成功但 /dev/led 不存在device_create失敗或者 udev 沒有收到事件dmesg看是否有failed to create device檢查 class_create 是否成功/dev/led 存在但 open 失敗設備節(jié)點權限不足或 cdev_add 順序有問題sudo chmod 666 /dev/led臨時測試寫 udev 規(guī)則做永久處理open 成功但 echo 報錯copy_from_user失敗或 write 邏輯返回負數(shù)回到驅(qū)動代碼檢查 fops 里 write 是否注冊成功rmmod 報仍在占用有進程打開著 /dev/ledfuser -v /dev/led查看占用進程關閉后再卸載加載時設備號沖突register_chrdev_region 指定的 major 被占用cat /proc/devices查詢改用動態(tài)分配或換號特別說一下/dev/led權限問題。device_create創(chuàng)建的節(jié)點默認屬主是 root權限是 0600所以普通用戶echo進去必然被拒。臨時測試用chmod 666沒問題產(chǎn)品上建議寫一個 udev 規(guī)則按 class 和 subsystem 給設備節(jié)點設置權限組這樣每次開機自動生效不依賴手動改權限。6.3 動態(tài)主設備號對應用透明嗎這是許多新手最后會糾結的問題如果每次加載主設備號都變那我應用程序里寫死的mknod或者open路徑怎么辦答案是不用擔心。/dev/led這個節(jié)點名是device_create最后一個參數(shù)決定的和主設備號無關。應用層打開設備用的是路徑名真正打開時 VFS 會根據(jù)節(jié)點記錄的dev_t找到對應的cdev所以你完全不感知主設備號是多少。這也正是新版框架的價值設備號是內(nèi)核內(nèi)部資源應用只看到設備節(jié)點名。多 LED 場景就更好理解了。申請兩個次設備號device_create分別創(chuàng)建led0和led1應用行為完全一致驅(qū)動內(nèi)部通過iminor(inode)區(qū)分控制哪一路。LED 實驗跑通后建議你再補一個read方法和ioctl把整個字符設備驅(qū)動的骨架填滿后面寫按鍵、寫傳感器驅(qū)動時這套框架能直接復刻。最后提醒一句經(jīng)驗調(diào)試階段固定major241方便看現(xiàn)象但產(chǎn)品代碼里一定要默認走動態(tài)分配。我見過不止一次同事把測試時的固定設備號帶進量產(chǎn)程序結果目標板上那個號早被別的驅(qū)動占走驅(qū)動加載直接失敗排查大半天才反應過來。新版這套流程看著比老版多一些代碼但每一步都可控、可回滾、可定位等你能不看模板把這個鏈路默寫出來字符設備驅(qū)動基本上就入門了。