塊裝置驅動程式分析之記憶體模擬磁碟

#include

static struct gendisk *ramblock_disk;

static request_queue_t *ramblock_queue;

static int major;

static define_spinlock(ramblock_lock);

static struct block_device_operations ramblock_fops = ;

#define ramblock_size (1024*1024)

static unsigned char *ramblock_buf;

static void do_ramblock_request(request_queue_t * q)

else

end_request(req, 1);

//乙個請求處理完畢後要結束請求，才能處理下乙個請求 }

} static int ramblock_init(void)

static void ramblock_exit(void)

module_init(ramblock_init);

module_exit(ramblock_exit);

module_license("gpl");

總結：

在這個程式裡面，我們開闢了一塊記憶體區模擬這個磁碟。也就是說，我們對塊裝置的操作實際上是對這塊記憶體的操作。對於這塊記憶體的操作我們有必要來嘮叨一下：首先資料傳送肯定需要三個要素，一是源，二是目的，三是長度。我們需要對這些引數進行設定，所有的這些引數資訊都在req這個結構體裡面，其中req->sector表示下乙個要提交的扇區，那麼

ramblock_buf+

req->current_nr_sectors表示當前要處理的扇區的個數，那麼

req->current_nr_sectors就表示要處理的記憶體的長度。而讀資料時，讀出的資料放在

req->buffer中，寫資料時，要寫入的資料也在

req->buffer中，所以

req->buffer既是源也是目的。

其實說道這裡，我已經亂了。我已經完全不知道程式是如何執行的，所以我們還是從應用空間出來，在來囉嗦一遍：

我們以讀取為例，當應用空間讀塊裝置的時候，會呼叫ll_rw_block函式，然後會將請求放入到我們在驅動程式裡面申請的佇列裡面，但是此時不會處理該請求，當請求結束後，才開始處理所有的請求。這時就會呼叫我們註冊的佇列處理函式來處理佇列裡面的請求，處理請求的時候我們會根據電梯排程演算法乙個乙個取出請求來處理，當然取出請求的時候，需要獲得請求結構體，裡面記載了該請求的相關資訊，我們處理該請求需要依賴於這些資訊。而且每處理完乙個請求需要結束該請求，否則無法處理下乙個請求。但是我們需要知道，我們構造請求時候有合併請求，這就告訴我們，處理每個請求並不是處理乙個512位元組的塊，而是處理多個塊的組合。

測試：

（1）insmod block.ko

（2）格式化: mkdosfs /dev/ramblock

（3）掛接: mount /dev/ramblock /tmp/

（4）讀寫檔案: cd /tmp, 在裡面vi檔案，如vi text.c，在裡面寫入hello，ls命令可以看到text.c檔案，但是看不見tmp目錄下原來的檔案了

（5）解除安裝：cd /; umount /tmp/ 我們發現tmp目錄下面已經沒有text.c這檔案了，有的只是tmp目錄下原來的檔案。

以上我們將塊裝置掛接到tmp目錄下之後，tmp目錄就相當於塊裝置了。

塊裝置驅動程式分析之記憶體模擬磁碟

Linux塊裝置驅動之記憶體模擬塊裝置

塊裝置驅動之記憶體模擬硬碟

編寫塊裝置驅動之記憶體模擬磁碟

塊裝置驅動程式分析之記憶體模擬磁碟

Linux塊裝置驅動之記憶體模擬塊裝置

塊裝置驅動之記憶體模擬硬碟

編寫塊裝置驅動之記憶體模擬磁碟

相關推薦