Linux核心開發之非同步通知與非同步I O 一

2021-06-22 08:25:44 字數 2776 閱讀 6572

「小王,聽說過錦上添花吧..」我拍拍下王的頭說。

「還錦上添花你,為你上次提的幾個東東,我是頭上長包..」小王氣憤地瞪著我。

「啊,為啥這樣呢,本來還特意拒絕了mm的約會,抽出時間打算給你說點高階的東東,看來現在是不行了」我吃驚道,「這樣吧,這次就給你講些和前邊有關的東西,也不失為錦上添花不是?」。

「好,我也是這麼打算的,就是沒好意思說,今天講些啥呢?」小王暗淡的眼光總算閃了閃。(為啥這麼難受呢,好像跟什麼會嚎叫的特像,哈哈)

那就言歸正傳,今天我們講---linux裝置驅動程式之非同步通知與非同步i/o.」

小王,前邊不是講了阻塞與非阻塞訪問,poll()函式等提供的較好的解決裝置訪問的機制,那麼通過這次有關非同步通知整套機制的配合,就更相得益彰,錦上添花了。

啥叫非同步通知:很簡單,一旦裝置準備好,就主動通知應用程式,這種情況下應用程式就不需要查詢裝置狀態,這是不是特像硬體上常提的「中斷的概念」。上邊比較準確的說法其實應該叫做「訊號驅動的非同步i/o」,訊號是在軟體層次上對中斷機制的一種模擬。

「小王,給你乙個表現的機會,說說這個和前邊的幾點不同和差異。。」

「嗯,我的理解是這樣的哈,阻塞i/o意味著一直等待裝置可訪問再訪問,非阻塞i/o意味著使用poll()來查詢是否可訪問,而非同步通知則意味著裝置通知應用程式自身

可訪問。」看著小王聰明的眼睛和清晰的思路,我也忍不住給予乙個鼓勵的微笑啊。

說的好,我只是想強調一點:上面三種方式,其實本身是沒有優劣的,應該根據不同的應用場景合理選擇罷了。

說到訊號,在應用程式中,為了捕獲訊號(還捕獲呢, 不就是乙個處理嗎)可以使用signal()函式來設定對應的訊號的處理函式。函式原型是

void (*signal(int signo,void (*func)(int))) (int)   這個看起來費勁吧,不光你,我看著也費勁,沒關係,給你來個例子:

void sigterm_handler(int signo)

int main(void)

看了這段**明白啥意思了吧,我也不多少了,咱們繼續往下走..為了乙個使用者在使用者空間中能處理乙個裝置釋放的訊號,它必須完成一下3份工作:
1)通過f_setown控制指令設定裝置檔案的擁有者為本程序,這樣從裝置驅動中發出的訊號才能被本程序收到。
2)通過f_setflio控制命令設定裝置檔案支援fasync,即非同步通知模式。
3)通過signal()鏈結訊號和訊號處理函式。
當然,如果你了解linux/unix訊號機制的話,你可能會問為啥沒說sigaction函式,其實沒關係,作用差不多,想知道的話,自己看書apue的p261.
有了訊號的傳送,那麼就一定得有訊號的釋放了:
在裝置驅動和應用程式的非同步通知互動中,僅僅在應用程式端捕獲訊號是不夠的,因為訊號沒有的源頭是在驅動端,因此要在適當的時機讓裝置驅動釋放訊號。
為了使裝置支援非同步通知機制,驅動程式中涉及三個操作:
1)支援f_setown命令,能在這個控制命令處理中設定filp->f_owner為對應的程序id。不過此項工作已由核心完成,裝置驅動無須處理。
2)支援f_setfl命令的處理,每當fasync標誌改變時,驅動程式中fasync()函式將得以進行。因此,驅動程式必須實現fasync()函式。
3)在裝置資源可獲得時,呼叫kill_fasync()函式激發相應的訊號。
驅動程式中上面的三步是和應用程式是一一對應的。如下圖:

裝置驅動中非同步通知程式設計還是比較簡單的,主要就是一些資料結構,和兩個函式:

資料結構:fasync_struct結構體

函式:1)處理fasync標誌變更的函式int fasync_helper(int fd, struct file *filp, int mode ,struct fasync_struct **fa);

2) 釋放訊號用的函式void kill_fasync(struct fasync_struct **fa, int sig, int band);

和其他裝置驅動一樣,一般將fasync_struct放到裝置結構體中。下邊是典型模版:

struct ***_dev

而在驅動的fasync()函式中,只需要簡單的將該引數的3個引數以及fasync_struct結構體指標的指標作為第四個引數傳給fasync_helper函式即可.下邊是典型模版:

static

int ***_fasync(int fd, struct file *filp, int mode)

一旦裝置資源可以獲得時,應該呼叫kill_fasync()釋放sigio訊號,可讀時第三個引數設定為poll_in,可寫時第三個引數設定為poll_out,下邊是釋放訊號的典型模版:

static ssize_t ***_write(struct file *filp, const

char __user *buf, size_t count,loff_t *f_ops)..}

最後,在檔案關閉時,即在裝置驅動的release函式中,應呼叫裝置驅動的fasync()函式將檔案從非同步通知的列表中刪除,下邊是裝置驅動的釋放函式的典型模版:

static

int ***_release(struct inode *inode, struct file *filp)

「等等,我知道你明白,你是想向我個例子,我知道你啥意思,沒關係,我下次補上 。」沒等小王,我立刻給她堵上「你啊,心裡幾根小九九,我還不知道啊..」

Linux核心開發之非同步通知與非同步I O 二

曾經有乙份真摯的愛情擺在面前,我卻不懂珍惜 曾經有乙個承諾,我卻倍感珍惜,今天一定要好好講講.講講啥,講講上節說的那個非同步通知的例子唄,大家喜歡看 咋們就先上 struct globalfifo dev 檔案釋放函式 int globalfifo release struct inode inod...

Linux核心開發之非同步通知與非同步I O 五

小王呢,今天開始講aio與裝置驅動,這也是裝置驅動通知與非同步io的最後一節了,下次咱們就要開始講更高階的東西,比如中斷啦,時鐘等 在linux核心中,每個io請求都對應乙個kiocb結構體,其ki filp成員指向對應的file指標,通過is sync kiocb可以判斷某kiocb時候為同步io...

Linux核心開發之非同步通知與非同步I O 一

非同步通知 很簡單,一旦裝置準備好,就主動通知應用程式,這種情況下應用程式就不需要查詢裝置狀態,這是不是特像硬體上常提的 中斷的概念 上邊比較 準確的說法其實應該叫做 訊號驅動的非同步i o 訊號是在軟體層次上對中斷機制的一種模擬。阻塞i o意味著一直等待裝置可訪問時再訪問,非阻塞i o意味著使用p...