角色定得挺準(zhǔn)——設(shè)備驅(qū)動(dòng)工程師在不少人眼里確實(shí)帶著一層“神秘濾鏡”一來是平時(shí)很少直接接觸二來是薪資普遍不錯(cuò)網(wǎng)上還總有人說“沒個(gè)五年十年寫不了驅(qū)動(dòng)”。我在嵌入式Linux這個(gè)圈子里混了十來年從應(yīng)用層一路折騰到內(nèi)核態(tài)今天就把這層窗戶紙捅破。你可以把這篇內(nèi)容當(dāng)成一份完整的職業(yè)觀察筆記也可以當(dāng)成一份入門地圖我會(huì)把Linux設(shè)備驅(qū)動(dòng)工程師的真實(shí)工作內(nèi)容、核心技術(shù)棧、職業(yè)發(fā)展和入行路徑一次性講透包括我自己踩過的坑和復(fù)盤出來的經(jīng)驗(yàn)。無論你是在校學(xué)生、做應(yīng)用開發(fā)想轉(zhuǎn)內(nèi)核方向的老兵還是剛跳進(jìn)嵌入式行業(yè)的新人這篇都值得耐心讀完。1. “神秘感”是從哪來的這個(gè)崗位到底在做什么1.1 外界誤讀和真實(shí)工作場景的差距一提起設(shè)備驅(qū)動(dòng)工程師很多人的第一反應(yīng)是“寫底層的很厲害但是不知道他每天具體在干嘛”。實(shí)際上這個(gè)崗位的工作范圍非常清晰讓操作系統(tǒng)能正確控制某一塊硬件。以手機(jī)為例屏幕、攝像頭、觸摸屏、Wi-Fi模塊、傳感器、電池管理芯片每一類硬件都需要對應(yīng)的驅(qū)動(dòng)代碼操作系統(tǒng)才能調(diào)用它們干活。我一直覺得“神秘”這個(gè)印象主要來自三個(gè)原因第一驅(qū)動(dòng)代碼跑在內(nèi)核態(tài)普通應(yīng)用開發(fā)者一輩子可能都碰不到內(nèi)核源碼第二驅(qū)動(dòng)開發(fā)依賴具體硬件沒有開發(fā)板或者對應(yīng)的芯片文檔光看代碼很難建立實(shí)感第三內(nèi)核態(tài)出問題表現(xiàn)形式往往是系統(tǒng)崩潰、重啟、死機(jī)沒有應(yīng)用層那種清晰的報(bào)錯(cuò)堆棧排錯(cuò)難度看起來很高。但真實(shí)的工作場景其實(shí)沒那么玄乎。我日常做的事情大致可以分成五塊讀芯片手冊、看內(nèi)核現(xiàn)有框架、寫驅(qū)動(dòng)代碼、調(diào)試硬件交互、配合應(yīng)用層調(diào)接口。芯片手冊是最核心的輸入比如你要寫一個(gè)I2C溫濕度傳感器的驅(qū)動(dòng)第一步不是打開編輯器寫代碼而是把芯片的datasheet翻出來搞清楚寄存器地址、I2C從機(jī)地址、數(shù)據(jù)格式、轉(zhuǎn)換公式然后去找內(nèi)核現(xiàn)成的i2c_driver框架按規(guī)矩實(shí)現(xiàn)probe、remove、讀寫函數(shù)。1.2 為什么高薪高在哪里高薪這個(gè)問題我可以直接給結(jié)論這個(gè)崗位薪資高本質(zhì)上是供需關(guān)系和進(jìn)入門檻共同決定的。供給少是因?yàn)閮?nèi)核開發(fā)的學(xué)習(xí)曲線確實(shí)陡峭光是把Linux內(nèi)核的進(jìn)程調(diào)度、內(nèi)存管理、中斷系統(tǒng)、并發(fā)機(jī)制搞清楚就需要不短的時(shí)間需求多是因?yàn)楝F(xiàn)在的設(shè)備智能化程度越來越高從手機(jī)、汽車、路由器到醫(yī)療設(shè)備、工業(yè)控制器只要跑Linux系統(tǒng)就需要有人維護(hù)和編寫驅(qū)動(dòng)。另外還有一個(gè)容易被忽視的原因驅(qū)動(dòng)工程師承擔(dān)的責(zé)任邊界是模糊的。硬件工程師可以把鍋推給驅(qū)動(dòng)說你軟件沒配好應(yīng)用工程師也可以把鍋推給驅(qū)動(dòng)說我的數(shù)據(jù)一直讀不對。最后的定位環(huán)節(jié)往往是驅(qū)動(dòng)工程師拿邏輯分析儀、示波器一根線一根線地排查。這種“兜底”能力加上內(nèi)核態(tài)開發(fā)本身對系統(tǒng)穩(wěn)定性要求的嚴(yán)苛程度自然推高了崗位價(jià)值。這幾年我觀察到的一線薪酬區(qū)間是應(yīng)屆生如果能拿出像樣的內(nèi)核學(xué)習(xí)項(xiàng)目起步基本高于普通應(yīng)用開發(fā)三到五年經(jīng)驗(yàn)、能獨(dú)立負(fù)責(zé)一個(gè)SoC平臺(tái)bring-up的工程師在一線城市的薪資非常有競爭力如果你還能搞定音頻、Camera、網(wǎng)絡(luò)這類復(fù)雜度更高的子系統(tǒng)薪資天花板還能繼續(xù)往上走。1.3 這個(gè)崗位的真正門檻不是寫代碼而是讀懂約束寫驅(qū)動(dòng)代碼本身不復(fù)雜真正的門檻是讀懂硬件的約束。硬件不是軟件一些在應(yīng)用開發(fā)里完全不需要考慮的物理問題在這里必須時(shí)刻記在心里。比如寄存器寫入之后不是立刻生效的可能需要等待幾個(gè)時(shí)鐘周期某些寄存器是只讀的你不能想當(dāng)然地往里面寫值某些硬件模塊有嚴(yán)格的時(shí)序要求你在驅(qū)動(dòng)里加一個(gè)調(diào)試printk都可能破壞時(shí)序?qū)е略O(shè)備莫名其妙工作異常。這也是為什么我一直強(qiáng)調(diào)做驅(qū)動(dòng)開發(fā)耐心和細(xì)致比聰明更重要。聰明的頭腦能幫你快速理解框架但能不能沉下心來把200頁的芯片手冊啃完能不能一根信號一根信號地對照時(shí)序圖決定了你能在這個(gè)領(lǐng)域走多深。2. 最核心的入門骨架Linux字符設(shè)備驅(qū)動(dòng)框架拆解2.1 為什么從字符設(shè)備入手關(guān)于Linux設(shè)備驅(qū)動(dòng)網(wǎng)絡(luò)上被搜得最多的一個(gè)詞就是“字符設(shè)備驅(qū)動(dòng)框架”。這完全合理如果你對驅(qū)動(dòng)開發(fā)完全沒有概念字符設(shè)備就是最好的切入口。字符設(shè)備的典型特征是數(shù)據(jù)按字節(jié)流順序讀寫沒有固定大小的塊結(jié)構(gòu)。鍵盤、鼠標(biāo)、串口、溫度傳感器、LED燈全都是典型的字符設(shè)備。我見過不少新人一上來就想寫網(wǎng)絡(luò)驅(qū)動(dòng)或者USB驅(qū)動(dòng)我的建議是先打住。字符設(shè)備驅(qū)動(dòng)框架雖然簡單但它覆蓋了驅(qū)動(dòng)開發(fā)的完整生命周期模塊加載、設(shè)備注冊、文件操作接口實(shí)現(xiàn)、數(shù)據(jù)讀寫、模塊卸載。這個(gè)流程走通了你再看platform bus、PCI、USB、V4L2這些復(fù)雜的子系統(tǒng)會(huì)發(fā)現(xiàn)它們的核心骨架并沒有變只是掛接的總線和協(xié)議復(fù)雜了。2.2 框架里每個(gè)環(huán)節(jié)背后的“為什么”先看一個(gè)最精簡的字符設(shè)備驅(qū)動(dòng)骨架然后我再逐行拆解每個(gè)環(huán)節(jié)的用意。#include linux/module.h #include linux/fs.h #include linux/cdev.h #include linux/device.h #include linux/uaccess.h #define DEVICE_NAME mydemo #define CLASS_NAME mydemo_class static dev_t dev_num; static struct cdev my_cdev; static struct class *my_class; static struct device *my_device; static int demo_open(struct inode *inode, struct file *filp) { pr_info(mydemo: open called\n); return 0; } static ssize_t demo_read(struct file *filp, char __user *buf, size_t count, loff_t *offset) { char kernel_buf[64] hello from kernel\n; size_t len strlen(kernel_buf); int ret; if (count len) return -EINVAL; ret copy_to_user(buf, kernel_buf, len); if (ret) return -EFAULT; return len; } static ssize_t demo_write(struct file *filp, const char __user *buf, size_t count, loff_t *offset) { char kernel_buf[128]; int ret; if (count sizeof(kernel_buf)) return -EINVAL; ret copy_from_user(kernel_buf, buf, count); if (ret) return -EFAULT; kernel_buf[count] \0; pr_info(mydemo: received %s\n, kernel_buf); return count; } static int demo_release(struct inode *inode, struct file *filp) { pr_info(mydemo: release called\n); return 0; } static struct file_operations fops { .owner THIS_MODULE, .open demo_open, .read demo_read, .write demo_write, .release demo_release, }; static int __init demo_init(void) { int ret; ret alloc_chrdev_region(dev_num, 0, 1, DEVICE_NAME); if (ret 0) { pr_err(mydemo: failed to alloc region\n); return ret; } cdev_init(my_cdev, fops); my_cdev.owner THIS_MODULE; ret cdev_add(my_cdev, dev_num, 1); if (ret 0) { pr_err(mydemo: failed to add cdev\n); goto err_unregister; } my_class class_create(CLASS_NAME); if (IS_ERR(my_class)) { ret PTR_ERR(my_class); goto err_cdev_del; } my_device device_create(my_class, NULL, dev_num, NULL, DEVICE_NAME); if (IS_ERR(my_device)) { ret PTR_ERR(my_device); goto err_class_destroy; } pr_info(mydemo: init success, major %d minor %d\n, MAJOR(dev_num), MINOR(dev_num)); return 0; err_class_destroy: class_destroy(my_class); err_cdev_del: cdev_del(my_cdev); err_unregister: unregister_chrdev_region(dev_num, 1); return ret; } static void __exit demo_exit(void) { device_destroy(my_class, dev_num); class_destroy(my_class); cdev_del(my_cdev); unregister_chrdev_region(dev_num, 1); pr_info(mydemo: exit\n); } module_init(demo_init); module_exit(demo_exit); MODULE_LICENSE(GPL); MODULE_AUTHOR(Your Name); MODULE_DESCRIPTION(A simple character device driver demo);這個(gè)例子看起來代碼量不大每一行都至少對應(yīng)一個(gè)內(nèi)核機(jī)制。alloc_chrdev_region的作用是向內(nèi)核申請一個(gè)未使用的設(shè)備號設(shè)備號由主設(shè)備號和次設(shè)備號組成。主設(shè)備號用來關(guān)聯(lián)驅(qū)動(dòng)次設(shè)備號用來區(qū)分同一個(gè)驅(qū)動(dòng)下的不同設(shè)備。這里選擇動(dòng)態(tài)分配而不是寫死主設(shè)備號原則很簡單避免和系統(tǒng)已有的設(shè)備號沖突。cdev_init和cdev_add是把我們的file_operations結(jié)構(gòu)體注冊進(jìn)內(nèi)核的字符設(shè)備層。注冊成功之后用戶在應(yīng)用層打開/dev/mydemo這個(gè)節(jié)點(diǎn)內(nèi)核就能根據(jù)設(shè)備號找到對應(yīng)的cdev進(jìn)而找到我們實(shí)現(xiàn)的demo_open、demo_read這些函數(shù)。class和device的創(chuàng)建容易被新手當(dāng)成“可有可無的儀式感”其實(shí)非常關(guān)鍵。class_create之后再用device_create內(nèi)核會(huì)自動(dòng)在/sys/class/下生成設(shè)備信息并且讓設(shè)備節(jié)點(diǎn)在udev的配合下自動(dòng)出現(xiàn)在/dev/目錄里。沒有這一步你就只能手動(dòng)mknod創(chuàng)建設(shè)備節(jié)點(diǎn)節(jié)點(diǎn)號一旦對不上應(yīng)用層打不開設(shè)備調(diào)試體驗(yàn)極差。2.3 最容易被新手忽略的承上啟下問題框架寫完了怎么驗(yàn)證你需要在開發(fā)板上或者虛擬機(jī)里用make編譯這個(gè)模塊用內(nèi)核源碼目錄下的Makefile做外部模塊編譯然后依次執(zhí)行sudo insmod mydemo.ko lsmod | grep mydemo ls -l /dev/mydemo echo hello /dev/mydemo cat /dev/mydemo sudo rmmod mydemoecho和cat分別觸發(fā)write和read路徑如果一切正常read會(huì)返回hello from kernelwrite的字符串也會(huì)通過pr_info打印到內(nèi)核日志里用dmesg就能看到。很多人在這一步碰到的問題是編譯報(bào)錯(cuò)找不到linux/module.h。這通常是因?yàn)闆]有把內(nèi)核頭文件裝好或者編譯時(shí)KDIR指向了當(dāng)前系統(tǒng)的運(yùn)行內(nèi)核而不是有完整源碼的目錄。這里有個(gè)我自己常用的配置思路如果是開發(fā)板就在板子的Linux源碼目錄下建一個(gè)驅(qū)動(dòng)子目錄用內(nèi)核的obj-m機(jī)制來編譯如果是虛擬機(jī)裝好linux-headers-$(uname -r)再編譯基本能規(guī)避90%以上的頭文件問題。3. 從字符設(shè)備到真實(shí)項(xiàng)目繞過設(shè)備樹這一關(guān)不現(xiàn)實(shí)3.1 設(shè)備樹到底解決的是什么問題如果你搜“l(fā)inux設(shè)備驅(qū)動(dòng)”幾乎一定會(huì)碰到“設(shè)備樹”Device Tree, DTS這個(gè)詞這也是當(dāng)前嵌入式Linux驅(qū)動(dòng)開發(fā)繞不過去的核心概念。網(wǎng)上關(guān)于設(shè)備樹的討論很多但真正能把它講清楚的不多。我個(gè)人的理解方式是設(shè)備樹是嵌入式世界里硬件資源的登記冊。傳統(tǒng)的PC平臺(tái)硬件資源基本是標(biāo)準(zhǔn)的、固定的內(nèi)核啟動(dòng)時(shí)可以通過PCI總線枚舉和ACPI表來發(fā)現(xiàn)硬件但嵌入式平臺(tái)的硬件情況千差萬別同樣是i.MX6ULL芯片A廠商的板子GPIO1_IO03接的是一顆LEDB廠商的板子GPIO1_IO03接的卻可能是一顆按鍵。內(nèi)核如果寫死某個(gè)GPIO是LED換一塊板子就廢了。設(shè)備樹的作用就是把“哪顆引腳接了什么東西”這樣的信息從內(nèi)核源碼中抽離出來變成可以被bootloader加載、可以被內(nèi)核解析的數(shù)據(jù)描述。設(shè)備樹文件.dts編譯后生成.dtbbootloader啟動(dòng)內(nèi)核時(shí)把.dtb傳給內(nèi)核內(nèi)核通過解析設(shè)備樹來知道當(dāng)前板子上有哪些設(shè)備、寄存器地址是什么、中斷號是多少、引腳配置怎樣然后創(chuàng)建對應(yīng)的platform_device最終觸發(fā)我們驅(qū)動(dòng)里的probe函數(shù)。3.2 probe函數(shù)的匹配邏輯和常見翻車點(diǎn)一個(gè)platform驅(qū)動(dòng)核心入口不再是init函數(shù)里主動(dòng)注冊設(shè)備而是靠設(shè)備樹里的compatible字符串和驅(qū)動(dòng)里的of_match_table進(jìn)行匹配。以我手頭一個(gè)GPIO LED的驅(qū)動(dòng)為例設(shè)備樹節(jié)點(diǎn)可能是這樣的myled { compatible mycompany,myled; gpio-led gpio1 3 GPIO_ACTIVE_HIGH; };驅(qū)動(dòng)側(cè)的關(guān)鍵代碼是static const struct of_device_id myled_of_match[] { { .compatible mycompany,myled }, {} }; MODULE_DEVICE_TABLE(of, myled_of_match); static struct platform_driver myled_driver { .probe myled_probe, .remove myled_remove, .driver { .name myled, .of_match_table myled_of_match, }, }; module_platform_driver(myled_driver);這里最常見的翻車場景有兩個(gè)。第一設(shè)備樹里compatible寫的是mycompany,myled驅(qū)動(dòng)里匹配表卻寫成了mycompany,my-led一個(gè)連字符之差probe函數(shù)永遠(yuǎn)不被調(diào)用第二修改設(shè)備樹源碼之后沒有重新編譯生成.dtb并更新到boot分區(qū)bootloader加載的還是老版本設(shè)備樹你調(diào)試一天都找不到原因。我在實(shí)際項(xiàng)目中排查過很多次這類問題經(jīng)驗(yàn)是先讀/sys/firmware/devicetree/base/目錄看內(nèi)核解析到的設(shè)備樹內(nèi)容是不是你修改后的版本再查/sys/bus/platform/devices/下有沒有生成對應(yīng)的設(shè)備節(jié)點(diǎn)最后看內(nèi)核日志里是否打印了platform myled: Driver myled requests probe deferral這類提示。按照這個(gè)鏈路排查基本能快速定位是設(shè)備樹沒生效、還是驅(qū)動(dòng)匹配失敗。3.3 怎樣讀設(shè)備樹又不被繞暈初學(xué)設(shè)備樹你會(huì)看到一大堆reg、interrupts、clocks、pinctrl屬性。我的建議是不要試圖一把抓全先把最常用的幾個(gè)搞懂compatible負(fù)責(zé)匹配驅(qū)動(dòng)reg負(fù)責(zé)描述寄存器地址和長度interrupts負(fù)責(zé)中斷號gpio相關(guān)屬性負(fù)責(zé)引腳操作clocks負(fù)責(zé)時(shí)鐘關(guān)聯(lián)。等你能讀懂一份簡單的i.MX或者全志平臺(tái)設(shè)備樹時(shí)再去看內(nèi)核的Documentation/devicetree/bindings/目錄那里面有每個(gè)設(shè)備類型對應(yīng)的bindings文檔是官方欽定的設(shè)備樹屬性說明。遇到不熟悉的IP對應(yīng)的bindings文檔一定要看屬性名寫錯(cuò)一個(gè)字符驅(qū)動(dòng)probe都可能失敗。4. 內(nèi)核態(tài)和用戶態(tài)的邊界數(shù)據(jù)交互是驅(qū)動(dòng)開發(fā)的命門4.1 copy_to_user和copy_from_user不是隨便用的寫字符設(shè)備驅(qū)動(dòng)時(shí)你一定會(huì)用到copy_to_user和copy_from_user。為什么不能直接用memcpy呢原因有兩點(diǎn)。第一用戶態(tài)指針是虛擬地址內(nèi)核態(tài)不能假設(shè)它指向的物理內(nèi)存一定可訪問第二內(nèi)核必須保證安全性不能因?yàn)橛脩魝魅胍粋€(gè)野指針就讓內(nèi)核崩潰。copy_to_user和copy_from_user內(nèi)部會(huì)做地址合法性檢查并且根據(jù)當(dāng)前進(jìn)程的頁表來完成用戶態(tài)和內(nèi)核態(tài)之間的數(shù)據(jù)拷貝。如果拷貝失敗會(huì)返回未拷貝完成的字節(jié)數(shù)。我在代碼里會(huì)刻意檢查這個(gè)返回值一旦非零直接返回-EFAULT給應(yīng)用層讓應(yīng)用層知道是地址傳錯(cuò)了還是緩沖區(qū)太小。4.2 為什么需要ioctl它在實(shí)際項(xiàng)目中怎么用在應(yīng)用開發(fā)里你調(diào)用read和write就能完成大部分?jǐn)?shù)據(jù)交互但到了驅(qū)動(dòng)開發(fā)很多操作無法用“讀”或“寫”來抽象。比如你想讓串口驅(qū)動(dòng)修改波特率讓攝像頭驅(qū)動(dòng)切換分辨率讓LED驅(qū)動(dòng)改變閃爍模式這時(shí)候就需要ioctl。它本質(zhì)上是一個(gè)命令分發(fā)器通過不同的cmd告訴驅(qū)動(dòng)“我要做什么”。一個(gè)簡單的LED驅(qū)動(dòng)我通常會(huì)這樣定義命令#define MYLED_MAGIC L #define MYLED_SET_ON _IO(MYLED_MAGIC, 1) #define MYLED_SET_OFF _IO(MYLED_MAGIC, 2) #define MYLED_GET_STATE _IOR(MYLED_MAGIC, 3, int)然后在file_operations里實(shí)現(xiàn).unlocked_ioctl。用戶態(tài)通過ioctl(fd, MYLED_SET_ON)來點(diǎn)亮LED。需要注意的是現(xiàn)代內(nèi)核里一般用unlocked_ioctl而老的ioctl字段已經(jīng)被移除了。做驅(qū)動(dòng)開發(fā)時(shí)如果抄到老代碼編譯報(bào)錯(cuò)不要慌把.ioctl改成.unlocked_ioctl往往就好了。4.3 mmap高吞吐場景下的終極方案如果驅(qū)動(dòng)和應(yīng)用層之間需要頻繁傳遞大量數(shù)據(jù)比如攝像頭采集的幀數(shù)據(jù)、GPU處理后的圖像數(shù)據(jù)用read/write拷貝來拷貝去性能是不行的。這時(shí)候可以用mmap讓用戶態(tài)進(jìn)程直接把設(shè)備的物理內(nèi)存映射到自己的虛擬地址空間省掉內(nèi)核態(tài)的中間拷貝。我在實(shí)際項(xiàng)目里用mmap做過圖像傳感器數(shù)據(jù)采集吞吐量確實(shí)提升明顯但它也引入了新的復(fù)雜度。最典型的問題是緩存一致性CPU和設(shè)備DMA同時(shí)對同一塊內(nèi)存操作時(shí)可能會(huì)出現(xiàn)數(shù)據(jù)不一致。你需要搞清楚是否要調(diào)用dma_alloc_coherent分配一致內(nèi)存或者用dma_map_single配合適當(dāng)?shù)耐浇涌趤砭S護(hù)cache。這塊知識(shí)點(diǎn)比較深入新手階段可以先了解mmap能解決什么問題、引入什么代價(jià)等真正做視頻方向時(shí)再深入。5. 并發(fā)、中斷和時(shí)間驅(qū)動(dòng)工程師真正燒腦的三座山5.1 并發(fā)場景比應(yīng)用開發(fā)殘酷得多應(yīng)用開發(fā)里用多線程處理并發(fā)加把鎖基本能解決大部分問題驅(qū)動(dòng)開發(fā)里并發(fā)可能來自進(jìn)程上下文、中斷上下文、多核CPU同時(shí)訪問還有底半部機(jī)制tasklet、workqueue、軟中斷。任何一條路徑上對共享數(shù)據(jù)的非原子訪問都可能引起競態(tài)條件。踩過坑之后我才理解驅(qū)動(dòng)里加鎖的第一原則不是“所有地方都加”而是“明確每個(gè)共享數(shù)據(jù)的保護(hù)責(zé)任”。自旋鎖適合臨界區(qū)很短、不能在持有鎖時(shí)睡眠的場景互斥鎖適合臨界區(qū)較長、允許睡眠的場景。如果在自旋鎖里調(diào)用了一個(gè)可能睡眠的函數(shù)比如kmalloc時(shí)用了GFP_KERNEL系統(tǒng)可能會(huì)在持鎖期間被調(diào)度出去死鎖就是大概率的事情。5.2 中斷上下文里不能做的那些事中斷處理是驅(qū)動(dòng)開發(fā)中另一個(gè)容易翻車的領(lǐng)域。硬件觸發(fā)中斷后CPU會(huì)跳到中斷處理函數(shù)此時(shí)系統(tǒng)處于中斷上下文很多常規(guī)操作是被禁止的。比如你不能直接調(diào)用會(huì)睡眠的函數(shù)wait_event、mutex_lock至少要避免不能訪問用戶空間甚至獲取某些鎖也要特別小心。正確的套路是頂半部加底半部上半部handler里只做最緊急的事比如讀取硬件狀態(tài)寄存器、清除中斷標(biāo)志、把數(shù)據(jù)放入緩沖區(qū)然后觸發(fā)底半部底半部里再處理真正耗時(shí)的操作比如數(shù)據(jù)解析、喚醒等待隊(duì)列。常用的底半部機(jī)制有tasklet、workqueue和threaded IRQ。我的習(xí)慣是能用request_threaded_irq就用中斷線程化主中斷處理函數(shù)里只做標(biāo)記和確認(rèn)其余工作全部丟給線程簡單清晰也不容易出問題。5.3 時(shí)間感知和延時(shí)操作驅(qū)動(dòng)工程師必須對時(shí)間敏感。硬件操作里經(jīng)常需要微秒級延時(shí)比如傳感器上電后要等10ms才能開始I2C通信寄存器寫完后要等100微秒才能讀狀態(tài)。在內(nèi)核態(tài)不同精度的延時(shí)函數(shù)適用場景完全不同我按自己的經(jīng)驗(yàn)整理了一個(gè)參考表函數(shù)精度適用場景注意事項(xiàng)udelay微秒級忙等待不可睡眠時(shí)用長延時(shí)浪費(fèi)CPU小于10us建議用它mdelay毫秒級基于udelay封裝不推薦用于長延時(shí)的輪詢場景usleep_range微秒到毫秒允許睡眠的上下文比udelay省電推薦在進(jìn)程上下文用msleep毫秒級允許睡眠實(shí)際睡眠時(shí)間可能比請求值長schedule_timeout任意讓出CPU直到超時(shí)常用于等待特定條件踩過的坑是在中斷上下文誤用usleep_range。它其實(shí)會(huì)調(diào)度睡眠中斷上下文里一調(diào)用系統(tǒng)直接報(bào)BUG: sleeping function called from invalid context。看到這個(gè)報(bào)錯(cuò)先檢查你的調(diào)用點(diǎn)是不是在中斷里。5.4 大規(guī)模并發(fā)調(diào)試的笨辦法和巧辦法內(nèi)核并發(fā)問題復(fù)現(xiàn)困難調(diào)試更困難。我的經(jīng)驗(yàn)是按這個(gè)順序來先靠代碼審查把每個(gè)共享變量的訪問路徑列出來畫出可能發(fā)生競態(tài)的組合這一步能解決七成問題再用lockdep檢測死鎖開機(jī)參數(shù)里加lockdep如果代碼存在鎖序問題內(nèi)核會(huì)打印詳細(xì)的死鎖報(bào)告最后才是我個(gè)人最喜歡的bpf工具在開發(fā)板上用bpftrace掛到特定的內(nèi)核函數(shù)上統(tǒng)計(jì)鎖等待時(shí)間、臨界區(qū)執(zhí)行時(shí)間比盲目加printk高效得多。6. 驅(qū)動(dòng)開發(fā)的支撐生態(tài)調(diào)試工具與真實(shí)項(xiàng)目工作流6.1 沒有示波器和邏輯分析儀你寸步難行很多人寫驅(qū)動(dòng)把精力全部放在代碼上忽略了硬件調(diào)試工具的重要性。我的觀點(diǎn)是驅(qū)動(dòng)工程師的必備裝備不只是鍵盤還有邏輯分析儀和示波器。調(diào)I2C設(shè)備時(shí)邏輯分析儀能直接抓出SDA和SCL上的波形對照芯片手冊的時(shí)序圖一眼就能看出是不是地址錯(cuò)了、ACK位丟了調(diào)UART時(shí)波形能告訴你波特率是否匹配。kernelside的軟件調(diào)試手段當(dāng)然也重要。dmesg看內(nèi)核日志/proc和/sys接口看運(yùn)行時(shí)狀態(tài)ftrace追蹤函數(shù)調(diào)用棧printk雖然笨但好用。不過我真心的建議是屬性調(diào)試信息不要直接丟在release版本里可以用pr_debug加動(dòng)態(tài)調(diào)試開關(guān)看日志時(shí)通過/sys/kernel/debug/dynamic_debug/按模塊開啟這樣既保留了排查能力又不拖累線上性能。6.2 一個(gè)真實(shí)的驅(qū)動(dòng)開發(fā)迭代過程我把一個(gè)典型的驅(qū)動(dòng)開發(fā)任務(wù)拆成六個(gè)階段方便你對照自己的工作流有沒有遺漏。階段一拿到硬件和芯片手冊先做“靜態(tài)資料分析”把寄存器、中斷、引腳定義列成清單搞清楚這個(gè)設(shè)備在內(nèi)核里屬于哪一類子系統(tǒng)有沒有現(xiàn)成的驅(qū)動(dòng)框架可以復(fù)用。階段二搭好最小驗(yàn)證環(huán)境確認(rèn)開發(fā)板能啟動(dòng)系統(tǒng)能加載HelloWorld模塊串口和網(wǎng)絡(luò)調(diào)試通道都可用。階段三實(shí)現(xiàn)設(shè)備樹節(jié)點(diǎn)和probe函數(shù)先不急著做業(yè)務(wù)功能只驗(yàn)證“驅(qū)動(dòng)能被正確綁定到設(shè)備”。階段四實(shí)現(xiàn)基礎(chǔ)讀寫接口用簡單的read/write把寄存器讀出來驗(yàn)證硬件寄存器映射是否正確。階段五補(bǔ)齊中斷、并發(fā)、數(shù)據(jù)交互等完整邏輯這階段最耗時(shí)也是問題的高發(fā)期。階段六穩(wěn)定性測試和優(yōu)化連續(xù)運(yùn)行、并發(fā)壓力、異?；謴?fù)這些都要覆蓋。6.3 沒有開發(fā)板也能學(xué)嗎模擬環(huán)境是起步利器看到這里如果你還沒有任何硬件但想開始學(xué)驅(qū)動(dòng)完全可以從虛擬環(huán)境起步。QEMU可以模擬一個(gè)完整的ARM開發(fā)板很多開源項(xiàng)目分配了可以運(yùn)行的“virt”機(jī)器你可以在純軟件的Ubuntu主機(jī)上編譯內(nèi)核、加載模塊、創(chuàng)建設(shè)備節(jié)點(diǎn)、用應(yīng)用層程序調(diào)用底層驅(qū)動(dòng)。嵌入式Linux社區(qū)也提供了很多現(xiàn)成的QEMU鏡像自帶內(nèi)核源碼、工具鏈和文件系統(tǒng)你只要按文檔跑起來就能完成字符設(shè)備驅(qū)動(dòng)、中斷驅(qū)動(dòng)甚至簡單的gpio模擬。我個(gè)人當(dāng)年還用過另一種組合在虛擬機(jī)里跑一個(gè)老版本內(nèi)核的發(fā)行版比如Ubuntu 20.04自己下載對應(yīng)內(nèi)核源碼重新編譯然后用qemu-system-x86_64加載這個(gè)新內(nèi)核在里面做驅(qū)動(dòng)實(shí)驗(yàn)。雖然不如真實(shí)開發(fā)板來得直觀但用來理解框架和API綽綽有余。7. 入行路徑與面試考察點(diǎn)從我面試和被面試的經(jīng)驗(yàn)說起7.1 想從應(yīng)用開發(fā)轉(zhuǎn)驅(qū)動(dòng)需要補(bǔ)哪些課經(jīng)常有人問我現(xiàn)在做Linux應(yīng)用開發(fā)轉(zhuǎn)驅(qū)動(dòng)方向需要準(zhǔn)備什么我的建議是從三個(gè)方面入手。C語言要重新按內(nèi)核風(fēng)格來練。內(nèi)核用的是C89風(fēng)格、GNU擴(kuò)展不能依賴各種庫函數(shù)不能隨便用printf很多操作要自己操作鏈表和哈希表。建議先精讀Linux內(nèi)核源碼里的include/linux/list.h把鏈表操作練熟。操作系統(tǒng)基礎(chǔ)要補(bǔ)充到內(nèi)核級進(jìn)程調(diào)度、內(nèi)存管理、中斷機(jī)制這些不能只停留在概念上要能結(jié)合源碼說出實(shí)現(xiàn)。硬件知識(shí)要補(bǔ)起來至少能看懂芯片手冊理解GPIO、I2C、SPI這些接口的基本時(shí)序。7.2 面試官到底在面試什么面試時(shí)很多候選人的簡歷寫得很漂亮項(xiàng)目經(jīng)歷里堆了各種技術(shù)名詞但一問細(xì)節(jié)就露餡。設(shè)備驅(qū)動(dòng)方向的面試我個(gè)人關(guān)注的點(diǎn)通常有這幾個(gè)第一內(nèi)核模塊的加載和卸載流程是什么module_init的機(jī)制你怎么理解第二字符設(shè)備驅(qū)動(dòng)注冊需要哪些步驟設(shè)備號怎么分配第三中斷上下文中哪些事情不能做第四自旋鎖和互斥鎖的區(qū)別什么場景用哪個(gè)第五設(shè)備樹的作用和匹配流程。此外我會(huì)故意問一些“看起來簡單但需要真懂”的問題比如printk能用在中斷上下文嗎copy_to_user失敗返回什么這些問題不是考背概念而是看你能不能基于底層原理做出正確判斷。7.3 長期成長路徑從驅(qū)動(dòng)工程師到系統(tǒng)級工程師設(shè)備驅(qū)動(dòng)這個(gè)崗位長期發(fā)展路線其實(shí)很寬。你可以往某個(gè)垂直子系統(tǒng)方向深耕比如成為音頻系統(tǒng)工程師、Camera系統(tǒng)工程師、網(wǎng)絡(luò)驅(qū)動(dòng)專家也可以從驅(qū)動(dòng)拓展到整個(gè)內(nèi)核子系統(tǒng)往內(nèi)核內(nèi)存管理、調(diào)度器方向發(fā)展還可以往系統(tǒng)級架構(gòu)走涵蓋bootloader、內(nèi)核裁剪、文件系統(tǒng)、功耗優(yōu)化、安全啟動(dòng)成為真正能hold住整個(gè)系統(tǒng)的系統(tǒng)級工程師。我自己比較強(qiáng)烈的感受是驅(qū)動(dòng)開發(fā)給的技術(shù)視野是整個(gè)Linux系統(tǒng)中比較獨(dú)特的一種——因?yàn)閺挠布拇嫫鞯絻?nèi)核框架到應(yīng)用接口要全鏈路理清持續(xù)做幾年之后你對“一個(gè)數(shù)據(jù)從硬件到用戶態(tài)到底經(jīng)歷了什么”會(huì)有非常清晰的認(rèn)知。這份“底層連接感”是驅(qū)動(dòng)工程師最值錢的長期資產(chǎn)。8. 寫在最后破除“神秘感”后這個(gè)方向值不值得投入設(shè)備驅(qū)動(dòng)工程師再神秘拆開來看也只是“通過內(nèi)核代碼讓硬件正確工作”的工程師。它高薪的原因并不神秘門檻不低、責(zé)任不小、供給有限。如果你正在思考要不要入這一行我想給你幾條非常實(shí)際的經(jīng)驗(yàn)。第一不要被“內(nèi)核很可怕”嚇退。Linux內(nèi)核源碼看似龐大但你不需要全部掌握。你只需要先吃透一條主線比如“字符設(shè)備怎么從應(yīng)用層到驅(qū)動(dòng)再到硬件”然后沿著這條線不斷向縱深擴(kuò)展內(nèi)核對你就不再是一團(tuán)迷霧。第二一定要買一塊開發(fā)板不用太貴正點(diǎn)原子或者野火的入門級板子就夠用了。有硬件在手上你才能真正把驅(qū)動(dòng)代碼跑起來才能真正理解中斷的實(shí)時(shí)性和設(shè)備的物理行為。第三保持寫筆記的習(xí)慣。驅(qū)動(dòng)力開發(fā)中各種宏定義、匹配規(guī)則、報(bào)錯(cuò)格式都不是一錘子買賣能記住的我這么多年下來遇到不明報(bào)錯(cuò)時(shí)翻自己筆記的次數(shù)遠(yuǎn)多于重新查代碼的次數(shù)。如果你正在找工作我會(huì)建議把“至少自己動(dòng)手寫一個(gè)完整驅(qū)動(dòng)項(xiàng)目”作為底線。這個(gè)項(xiàng)目不一定要多復(fù)雜但一定要完整——從設(shè)備樹節(jié)點(diǎn)到驅(qū)動(dòng)代碼到應(yīng)用層測試程序全套跑通。面試官看到這樣的項(xiàng)目基本能確認(rèn)你不是只搬運(yùn)過示例代碼的人。驅(qū)動(dòng)開發(fā)這條路前期確實(shí)燒腦但熬過那個(gè)“什么都連不上、什么都不知道為什么”的階段之后你會(huì)獲得一種極強(qiáng)的掌控感。那種你能清楚地知道系統(tǒng)每一層在干什么、每一個(gè)硬件行為背后邏輯的感覺是這份職業(yè)最迷人的地方。