摘要:我們就繼續以此為基礎,用保姆級的粒度一步一步操作,來討論一下字符設備驅動程序的編寫方法。如何使用新的函數來編寫字符設備驅動程序,下一篇文章再詳細討論。
作 者:道哥,10+年嵌入式開發老兵,專注于:C/C++、嵌入式、Linux。
關注下方公眾號,回復【書籍】,獲取 Linux、嵌入式領域經典書籍;回復【PDF】,獲取所有原創文章( PDF 格式)。
目錄
?
?
別人的經驗,我們的階梯!
大家好,我是道哥,今天我為大伙兒解說的技術知識點是:【字符設備的驅動程序】。
在上一篇文章中,討論的是Linux
系統中,驅動模塊的兩種編譯方式。
我們就繼續以此為基礎,用保姆級的粒度一步一步操作,來討論一下字符設備驅動程序的編寫方法。
這篇文章的實際操作部分,使用的是的 API 函數;
下一篇文章,再來演示新的 API 函數;
我在剛開始接觸Linux
驅動的時候,非常的困擾:注冊一個字符設備,怎么有這么多的 API 函數啊?
參考的每一篇文章中,使用的函數都不一樣,但是執行結果都是符合預期的!
比如下面這幾個:
register_chrdev(...);
register_chrdev_regin(...);
cdev_add(...);
它們的功能都是向系統注冊字符設備,但是只從函數名上看,初學者誰能分得清它們的區別?!
這也難怪,Linux
系統經過這么多年的發展,代碼更新是很正常的事情。
但是,我們參考的文章就沒法做到:很詳細的把文章中所描述內容的背景介紹清楚,往往都是文章作者在自己的實際工作環境中,測試某種方法解決了自己的問題,于是就記錄成文。
不同的文章、不同的工作上下文、不同的API
函數調用,這往往就苦了我們初學者,特別是我這種有選擇障礙癥的人!
其實,上面這個幾個函數都是正確的,它們的功能都是類似的,它們是 Linux
系統中不同階段的產物。
在Linux
內核代碼2.4
版本和早期的2.6
版本中,注冊、卸載字符設備驅動程序的經典方式是:
注冊設備:
int register_chrdev(unsigned int major,const char *name,struct file_operations *fops);
參數1 major: 如果為0 - 由操作系統動態分配一個主設備號給這個設備;如果非0 - 驅動程序向系統申請,使用這個主設備號;
參數2 name: 設備名稱;
參數3 fops: file_operations 類型的指針變量,用于操作設備;
如果是動態分配,那么這個函數的返回值就是:操作系統動態分配給這個設備的主設備號。
這個動態分配的設備號,我們要把它記住,因為在其他的API
函數中需要使用它。
卸載設備:
int unregister_chrdev(unsigned int major,const char *name)
參數1 major: 設備的主設備號,也就是 register_chrdev() 函數的返回值(動態),或者驅動程序指定的設備號(靜態方式);
參數2 name: 設備名稱;
注冊設備:
int register_chrdev_region(dev_t from, unsigned count, const char *name);int alloc_chrdev_region(dev_t *dev, unsigned baseminor, unsigned count,const char *name);
上面這2
個注冊設備的函數,其實對應著舊的 API 函數 register_chrdev
:把參數 1 表示的動態分配、靜態分配,拆分成2
個函數而已。
也就是說:
register_chrdev_region()
: 靜態注冊設備;
alloc_chrdev_region()
: 動態注冊設備;
這兩個函數的參數含義是:
register_chrdev_region
參數:
參數1 from: 注冊指定的設備號,這是靜態指定的,例如:MKDEV(200, 0) 表示起始主設備號 200, 起始次設備號為 0;
參數2 count: 驅動程序指定連續注冊的次設備號的個數,例如:起始次設備號是 0,count 為 10,表示驅動程序將會使用 0 ~ 9 這 10 個次設備號;
參數3 name:設備名稱;
alloc_chrdev_region
參數:
參數1 dev: 動態注冊就是系統來分配設備號,那么驅動程序就要提供一個指針變量來接收系統分配的結果(設備號);
參數2 baseminor: 驅動程序指定此設備號的起始值;
參數3 count: 驅動程序指定連續注冊的次設備號的個數,例如:起始次設備號是 0,count 為 10,表示驅動程序將會使用 0 ~ 9 這 10 個次設備號;
參數4 name:設備名稱;
補充一下關于設備號的內容:
這里的結構體 dev_t
,用來保存設備號,包括主設備號和次設備號。
它本質上是一個 32
位的數,其中的 12
位用來表示主設備號,而其余 20
位用來表示次設備號。
系統中定義了3
宏,來實現dev_t
變量、主設備號、次設備號之間的轉換:
MAJOR(dev_t dev): 從 dev_t 類型中獲取主設備號;
MINOR(dev_t dev): 從 dev_t 類型中獲取次設備號;
MKDEV(int major,int minor): 把主設備號和次設備號轉換為 dev_t 類型;
卸載設備:
void unregister_chrdev_region(dev_t from, unsigned count);
參數1 from: 注銷的設備號;
參數2 count: 注銷的連續次設備號的個數;
下面,我們就用舊的API
函數,一步一步的描述字符設備驅動程序的:編寫、加載和卸載過程。
如何使用新的 API 函數來編寫字符設備驅動程序,下一篇文章再詳細討論。
以下所有操作的工作目錄,都是與上一篇文章相同的,即:~/tmp/linux-4.15/drivers/
。
$ cd linux-4.15/drivers/$ mkdir my_driver1$ cd my_driver1$ touch driver1.c
driver1.c
文件的內容如下(不需要手敲,文末有代碼下載鏈接):
#include #include #include #include #include #include #include #include #include #include static unsigned int major;int driver1_open(struct inode *inode, struct file *file){ printk("driver1_open is called. /n"); return 0;}ssize_t driver1_read(struct file *file, char __user *buf, size_t size, loff_t *ppos){ printk("driver1_read is called. /n"); return 0;}ssize_t driver1_write (struct file *file, const char __user *buf, size_t size, loff_t *ppos){ printk("driver1_write is called. /n"); return 0;} static const struct file_operations driver1_ops={ .owner = THIS_MODULE, .open = driver1_open, .read = driver1_read, .write = driver1_write,};static int __init driver1_init(void){ printk("driver1_init is called. /n"); major = register_chrdev(0, "driver1", &driver1_ops); printk("register_chrdev. major = %d/n",major); return 0;} static void __exit driver1_exit(void){ printk("driver1_exit is called. /n"); unregister_chrdev(major,"driver1");} MODULE_LICENSE("GPL");module_init(driver1_init);module_exit(driver1_exit);
$ touch Makefile
內容如下:
ifneq ($(KERNELRELEASE),) obj-m := driver1.oelse KERNELDIR ?= /lib/modules/$(shell uname -r)/build PWD := $(shell pwd)default: $(MAKE) -C $(KERNELDIR) M=$(PWD) modulesclean: $(MAKE) -C $(KERNEL_PATH) M=$(PWD) cleanendif
$ make
得到驅動程序: driver1.ko 。
在加載驅動模塊之前,先來看一下系統中,幾個與驅動設備相關的地方。
先看一下 /dev 目錄下,目前還沒有我們的設備節點( /dev/driver1 )。
再來查看一下 /proc/devices 目錄下,也沒有 driver1
設備的設備號。
cat /proc/devices | grep driver1
/proc/devices 文件: 列出字符和塊設備的主設備號,以及分配到這些設備號的設備名稱。
執行如下指令,加載驅動各模塊:
$ sudo insmod driver1.ko
通過上一篇文章我們知道,當驅動程序被加載的時候,通過 module_init(driver1_init);
注冊的函數 driver1_init()
將會被執行,那么其中的打印信息就會輸出。
還是通過 dmesg
指令來查看驅動模塊的打印信息:
$ dmesg
如果輸入信息太多,可以使用
dmesg | tail
指令;
此時,驅動模塊已經被加載了!
來查看一下 /proc/devices 目錄下顯示的設備號:
可以看到 driver1
已經掛載好了,并且它的主設備號是244
。
此時,雖然已經向系統注冊了這個設備,并且主設備號已經分配了,但是,在/dev
目錄下,還不存在這個設備的節點,需要我們手動創建:
sudo mknod -m 660 /dev/driver1 c 244 0
檢查一下設備節點是否創建成功:
$ ls -l /dev
關于設備節點,Linux 的應用層有一個 udev 服務,可以自動創建設備節點;
也就是:當驅動模塊被加載的時候,自動在 /dev 目錄下創建設備節點。當然了,我們需要在驅動程序中,提前告訴 udev 如何去創建;
下面會介紹:如何自動創建設備節點。
現在,設備的驅動程序已經加載了,設備節點也被創建好了,應用程序就可以來操作(讀、寫)這個設備了。
我們把所有的應用程序,放在 ~/tmp/App/ 目錄下。
$ cd ~/tmp$ mkdir -p App/app_driver1$ touch app_driver1.c
app_driver1.c
文件的內容如下:
#include #include #include int main(void){ int ret; int read_data[4] = { 0 }; int write_data[4] = {1, 2, 3, 4}; int fd = open("/dev/driver1", O_RDWR); if (-1 != fd) { ret = read(fd, read_data, 4); printf("read ret = %d /n", ret); ret = write(fd, write_data, 4); printf("write ret = %d /n", ret); } else { printf("open /dev/driver1 failed! /n"); } return 0;}
這里演示的僅僅是通過打印信息來體現函數的調用,并沒有實際的讀取數據和寫入數據。
因為,讀寫數據又涉及到復雜的用戶空間和內核空間的數據拷貝問題。
應用程序準備妥當,接下來就是編譯和測試了:
$ gcc app_driver1.c -o app_driver1$ sudo ./app_driver1
應用程序的輸出信息如下:
app_driver1$ sudo ./app_driver1 [sudo] password for xxxx: <輸入用戶密碼>read ret = 0 write ret = 0
從返回值來看,成功打開了設備,并且調用讀函數、寫函數都成功了!
根據Linux
系統的驅動框架,應用層的 open、read、write 函數被調用的時候,驅動程序中對應的函數就會被執行:
static const struct file_operations driver1_ops={ .owner = THIS_MODULE, .open = driver1_open, .read = driver1_read, .write = driver1_write,};
我們已經在驅動程序的這三個函數中打印了信息,繼續用dmesg
命令查看一下:
卸載指令:
$ sudo rmmod driver1
繼續用dmesg
指令來查看驅動程序中的打印信息:
說明驅動程序中的 driver1_exit()
函數被調用了。
此時,我們來看一下 /proc/devices 目錄下變化:
可以看到:剛才設備號為244
的 driver1 已經被系統卸載了!因為驅動程序中的 unregister_chrdev(major,"driver1");
函數被執行了。
但是,由于 /dev 目錄下的設備節點 driver1 ,是剛才手動創建的,因此需要我們手動刪除。
$ sudo rm /dev/driver1
以上,就是字符設備的最簡單驅動程序!
從編寫過程可以看出:Linux
系統已經設計好了一套驅動程序的框架。
我們只需要按照它要求,按部就班地把每一個函數或者是結構體,注冊到系統中就可以了。
在上面的操作過程中,設備節點 /dev/driver1
是手動創建的。
Linux
系統的應用層提供了 udev 這個服務,可以幫助我們自動創建設備節點。我們現在就來把這個功能補上。
為了方便比較,添加的代碼全部用宏定義 UDEV_ENABLE 控制起來。
driver1.c
代碼中,有 3
處變化:
1. 定義 2 個全局變量
#ifdef UDEV_ENABLEstatic struct class *driver1_class;static struct device *driver1_dev;#endif
2. driver1_init() 函數
static int __init driver1_init(void){ printk("driver1_init is called. /n"); major = register_chrdev(0, "driver1", &driver1_ops); printk("register_chrdev. major = %d/n",major);#ifdef UDEV_ENABLE driver1_class = class_create(THIS_MODULE, "driver1"); driver1_dev = device_create(driver1_class, NULL, MKDEV(major, 0), NULL, "driver1");#endif return 0;}
3. driver1_exit() 函數
static void __exit driver1_exit(void){ printk("driver1_exit is called. /n");#ifdef UDEV_ENABLE class_destroy(driver1_class);#endif unregister_chrdev(major,"driver1");}
代碼修改之后(也可以直接下載我放在網盤里的源代碼),重新編譯驅動模塊:
$ make
生成driver1.ko
驅動模塊,然后加載它:
先確定一下:/proc/devices,/dev 目錄下,已經沒有剛才測試的設備了;
為了便于查看驅動程序中的打印信息,最好把 dmesg 輸出的打印信息清理一下(指令:sudo dmesg -c);
$ sudo insmod driver1.ko
按照剛才的操作流程,我們需要來驗證3
個信息:
(1) 看一下驅動程序的打印信息(指令:dmesg
):
(2) 看一下 /proc/devices
下的設備注冊情況:
(3) 看一下 /dev
下,是否自動創建了設備節點:
通過以上3
張圖片,可以得到結論:驅動程序正確加載了,設備節點被自動創建了!
下面,就應該是應用程序登場測試了,代碼不用修改,直接執行即可:
$ sudo ./app_driver1 [sudo] password for xxx: <輸入用戶密碼>read ret = 0 write ret = 0
應用層的函數返回值正確!
再看一下 dmesg
的輸出信息:
完美!
文中的所有代碼,已經放在網盤中了。
在公眾號【IOT物聯網小鎮】后臺回復關鍵字:1115,獲取下列文件的網盤地址。
?推薦閱讀
?
【1】《Linux 從頭學》系列文章
【2】C語言指針-從底層原理到花式技巧,用圖文和代碼幫你講解透徹
【3】原來gdb的底層調試原理這么簡單
【4】內聯匯編很可怕嗎?看完這篇文章,終結它!
其他系列專輯:精選文章、應用程序設計、物聯網、 C語言。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/123987.html
摘要:系列專欄博主結合工作實踐輸出的,解決實際問題的專欄,朋友們看過來開發實戰開發實戰嵌入式通用開發實戰嵌入式通用開發實戰 【系列專欄】:博主結合工作實踐輸出的,解決實際問題的專欄,朋友們看過來! 《QT開發實戰》 《嵌入式通用開發實戰》 《
摘要:產生的崩潰測試用例可能難以分析,因為模糊測試的行為并不能告訴你關于軟件內部運行方式的知識。模糊測試向軟件系統提供隨機輸入。 軟件質量保障 專注測試圈,自動化測試、測試平臺開發、測試新技術、大廠測試崗面經分享, 可以幫忙內推BATJ等大廠!歡迎加VX溝通交流: ISTE1024 測試同...
閱讀 2804·2021-11-19 11:35
閱讀 2582·2021-11-02 14:40
閱讀 1396·2021-09-04 16:48
閱讀 3009·2019-08-30 15:55
閱讀 1753·2019-08-30 13:11
閱讀 1955·2019-08-29 11:12
閱讀 1088·2019-08-27 10:52
閱讀 3157·2019-08-26 18:36