目錄

· 驅動程序

示例代碼全貌

Makefile 文件

編譯、測試

· 應用程序

示例代碼全貌

編譯、測試

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

大家好，我是道哥，今天我為大伙兒解說的技術知識點是：【中斷程序如何發送信號給應用層】。

最近分享的幾篇文章都比較基礎，關于字符類設備的驅動程序，以及中斷處理程序。

也許在現代的項目是用不到這樣的技術，但是萬丈高樓平地起。

只有明白了這些最基礎的知識點之后，再去看那些進化出來的高級玩意，才會有一步一個腳印的獲得感。

如果缺少了這些基礎的環節，很多深層次的東西，學起來就有點空中樓閣的感覺。

就好比研究Linux內核，如果一上來就從Linux 4．x／5．x內核版本開始研究，可以看到很多“歷史遺留”代碼。

這些代碼就見證著Linux一步一步的發展歷史，甚至有些人還會專門去研究 Linux 0．11 版本的內核源碼，因為很多基本思想都是一樣的。

今天這篇文章，主要還是以代碼實例為主，把之前的兩個知識點結合起來：

在中斷處理函數中，發送信號給應用層，以此來通知應用層處理響應的中斷業務。

驅動程序

示例代碼全貌

所有的操作都是在 ～／tmp／linux－4．15／drivers 目錄下完成的。

首先創建驅動模塊目錄：

＄ cd ～／tmp／linux－4．15／drivers

＄ mkdir my＿driver＿interrupt＿signal

＄ touch my＿driver＿interrupt＿signal．c

文件內容如下：

以上代碼主要做了兩件事情：

1． 注冊中斷號 1 的處理函數：myirq＿handler（）；

2． 創建設備節點 ／dev／mydev；

這里的中斷號1，是鍵盤中斷。

因為它是共享的中斷，因此當鍵盤被按下的時候，操作系統就會依次調用所有的中斷處理函數，當然就包括我們的驅動程序所注冊的這個函數。

中斷處理部分相關的幾處關鍵代碼如下：

在中斷處理函數中，目標是發送信號 SIGUSR1 到應用層，因此驅動程序需要知道應用程序的進程號（PID）。

根據之前的文章Linux驅動實踐：驅動程序如何發送【信號】給應用程序？，應用程序必須主動把自己的 PID 告訴驅動模塊才可以。這可以通過 write 或者ioctl函數來實現，

驅動程序用來接收 PID 的相關代碼是：

知道了應用程序的 PID，驅動程序就可以在中斷發生的時候（按下鍵盤ESC鍵），發送信號出去了：

Makefile 文件

編譯、測試

首先查看一下加載驅動模塊之前，1號中斷的所有驅動程序：

再看一下設備號：

＄ cat ／proc／devices

因為驅動注冊在創建設備節點的時候，是動態請求系統分配的。

根據之前的幾篇文章可以知道，系統一般會分配244這個主設備號給我們，此刻還不存在這個設備號。

編譯、加載驅動模塊：

＄ make

＄ sudo insmod my＿driver＿interrupt＿signal．ko

首先看一下 dmesg 的輸出信息：

然后看一下中斷驅動程序：

可以看到我們的驅動程序（ mydev ）已經登記在1號中斷的最右面。

最后看一下設備節點情況：

驅動模塊已經準備妥當，下面就是應用程序了。

應用程序

應用程序的主要功能就是兩部分：

通過 ioctl 函數把自己的 PID 告訴驅動程序；

注冊信號 SIGUSR1 的處理函數；

示例代碼全貌

在應用程序的最后，是一個 while（1） 死循環。因為只有在按下鍵盤上的ESC按鍵時，驅動程序才會發送信號上來，因此應用程序需要一直存活著。

編譯、測試

新開一個中斷窗口，編譯、執行應用程序：

由于應用程序調用了 open 和 ioctl 這兩個函數，因此，驅動程序中兩個對應的函數就會被執行。

這可以通過 dmesg 命令的輸出信息看出來：

這個時候，按下鍵盤上的 ESC 鍵，此時驅動程序中打印如下信息：

說明：驅動程序捕獲到了鍵盤上的 ESC 鍵，并且發送信號給應用程序了。

在執行應用程序的終端窗口中，可以看到如下輸出信息：

說明：應用程序接收到了驅動程序發來的信號！