Linux驅動實踐：你知道【字元裝置驅動程式】的兩種寫法嗎？

IOT物聯網小鎮發表於2021-11-19

Linux字元

作者：道哥，10+年嵌入式開發老兵，專注於：C/C++、嵌入式、Linux。

關注下方公眾號，回覆【書籍】，獲取 Linux、嵌入式領域經典書籍；回覆【PDF】，獲取所有原創文章( PDF 格式)。

別人的經驗，我們的階梯！

大家好，我是道哥，今天我為大夥兒解說的技術知識點是：【字元裝置的驅動程式】。

在上一篇文章中，討論的是Linux系統中，驅動模組的兩種編譯方式。

我們就繼續以此為基礎，用保姆級的粒度一步一步操作，來討論一下字元裝置驅動程式的編寫方法。

這篇文章的實際操作部分，使用的是的 API 函式;

下一篇文章，再來演示新的 API 函式;

混亂的 API 函式

我在剛開始接觸Linux驅動的時候，非常的困擾：註冊一個字元裝置，怎麼有這麼多的 API 函式啊？

參考的每一篇文章中，使用的函式都不一樣，但是執行結果都是符合預期的！

比如下面這幾個：

register_chrdev(...);

register_chrdev_regin(...);

cdev_add(...);

它們的功能都是向系統註冊字元裝置，但是隻從函式名上看，初學者誰能分得清它們的區別？！

這也難怪，Linux系統經過這麼多年的發展，程式碼更新是很正常的事情。

但是，我們參考的文章就沒法做到：很詳細的把文章中所描述內容的背景介紹清楚，往往都是文章作者在自己的實際工作環境中，測試某種方法解決了自己的問題，於是就記錄成文。

不同的文章、不同的工作上下文、不同的API函式呼叫，這往往就苦了我們初學者，特別是我這種有選擇障礙症的人！

其實，上面這個幾個函式都是正確的，它們的功能都是類似的，它們是 Linux 系統中不同階段的產物。

舊的 API 函式

在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：裝置名稱；

新的 API 函式

註冊裝置：

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 <linux module.h="">
#include <linux kernel.h="">
#include <linux fs.h="">
#include <linux init.h="">
#include <linux delay.h="">
#include <linux uaccess.h="">
#include <linux ctype.h="">
#include <linux irq.h="">
#include <linux io.h="">
#include <linux device.h="">

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);

建立 Makefile 檔案

$ touch Makefile

內容如下：

ifneq ($(KERNELRELEASE),)
	obj-m := driver1.o
else
	KERNELDIR ?= /lib/modules/$(shell uname -r)/build
	PWD := $(shell pwd)
default:
	$(MAKE) -C $(KERNELDIR) M=$(PWD) modules
clean:
	$(MAKE) -C $(KERNEL_PATH) M=$(PWD) clean
endif

編譯驅動模組

$ 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 <stdio.h>
#include <unistd.h>
#include <fcntl.h>


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 目錄下建立裝置節點

在上面的操作過程中，裝置節點 /dev/driver1 是手動建立的。

Linux 系統的應用層提供了 udev 這個服務，可以幫助我們自動建立裝置節點。我們現在就來把這個功能補上。

修改驅動程式

為了方便比較，新增的程式碼全部用巨集定義 UDEV_ENABLE 控制起來。

driver1.c程式碼中，有 3 處變化：

1. 定義 2 個全域性變數

#ifdef UDEV_ENABLE
static 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，獲取下列檔案的網盤地址。

------ End ------