1. 程式人生 > >linux0.11字元裝置的讀寫過程分析

linux0.11字元裝置的讀寫過程分析

首先要知道linux系統/dev目錄下的各種裝置檔案(檔案屬性c打頭)並不佔用空間,你可以發現他們的大小為0位元組,他們的區別在於檔案的i節點的成員i_zone[0]的值不同,該值標識不同的裝置號。比如tty0檔案的裝置號為0x0400,tty1裝置號為0x0401,hd0裝置號為0x0300,hd1裝置號為0x0301等。而這個裝置號裡面又包含兩部分內容:高位元組標識不同類裝置,比如tty0和hd0分別為0x04,0x03,低位元組標識同一類裝置不同序號。

接下來對linux0.11開啟的第一個檔案tty0的過程進行分析:

1. main.c檔案:執行open("/dev/tty0",O_RDWR,0),呼叫該函式將觸發系統呼叫sys_open()。

2.

open.c檔案:進入該系統呼叫函式sys_open,首先分配一個檔案控制代碼fd(第一個檔案為0,其實是檔案表到索引),然後為這個開啟的檔案在檔案表(file_table.c定義的一個數組)中尋找一個有效的空閒項,將這個空閒項的檔案指標新增到當前程序結構的flip成員中(flip成員為一個指標陣列),並將檔案引用次數+1。接著呼叫open_namei函式獲取tty0裝置檔案的i_node指標。最後將該指標賦給檔案表的f_inode成員。至此,tty0檔案開啟完畢,並將其inode資訊保存於current程序的flips陣列指標的fd索引項中。接下來開始對該tty進行寫操作。

3. main.c檔案:

呼叫printf函式執行列印輸出,在該函式中將呼叫write函式,又將觸發sys_write系統呼叫。

4. read_write.c檔案:進入sys_write系統呼叫函式,首先根據傳遞進來的檔案控制代碼fd獲取當前程序的檔案結構指標(file=current->filp[fd])),然後根據檔案結構指標的f_inode成員的i_mode成員判斷檔案的型別(根據前面open所獲取到型別,這裡應為i_mode=0x0400),判斷為字元裝置,因此呼叫字元裝置讀寫函式rw_char。(可以發現如果是塊裝置則呼叫block_write函式,如果是普通則呼叫file_write函式,當然讀其他裝置是同樣道理。這也印證了linux平臺下一切皆檔案的思想)

5. char_dev.c檔案:進入rw_char函式,根據傳遞進來的裝置號(0x0400)獲取對應讀寫函式指標(裝置號高位元組0x04對應函式指標陣列crw_table[]的rw_ttyx成員項),然後將執行rw_ttyx函式,該函式又呼叫tty_write底層函式。

6. tty_io.c檔案:進入tty_write函式,根據傳遞進來的裝置號低位元組(裝置序號,這裡為0x00)獲取tty_struct指標,根據該檔案開頭處定義的已初始化的tty結構陣列tty_table,該指標將指向tty_table陣列第一項(tty控制檯),tty_write函式最後執行tty->write語句將呼叫con_write函式對顯示器進行寫操作。

7. console.c檔案:con_write函式。

相關推薦

linux0.11字元裝置過程分析

首先要知道linux系統/dev目錄下的各種裝置檔案(檔案屬性c打頭)並不佔用空間,你可以發現他們的大小為0位元組,他們的區別在於檔案的i節點的成員i_zone[0]的值不同,該值標識不同的裝置號。比如tty0檔案的裝置號為0x0400,tty1裝置號為0x0401,hd0

第一個lucene程式,把一個資訊寫入到索引庫中、根據關鍵詞把物件從索引庫中提取出來、lucene過程分析

新建一個Java Project :LuceneTest 準備lucene的jar包,要加入的jar包至少有:1)lucene-core-3.1.0.jar     (核心包) 2)lucene-analyzers-3.1.0.jar    (分詞器) 3)lucene-h

ceph學習筆記之六 數據過程

ceph sds 數據寫過程1、Client向PG所在的主OSD發送寫請求。2、主OSD接收到寫請求,同時向兩個從OSD發送寫副本的請求,並同時寫入主OSD的本地存儲中。3、主OSD接收到兩個從OSD發送寫成功的ACK應答,同時確認自己寫成功,就向客戶端返回寫成功的ACK應答。4、在寫操作的過程中,主

Hbase過程

  和寫流程相比,HBase讀資料是一個更加複雜的操作流程,這主要基於兩個方面的原因:其一是因為整個HBase儲存引擎基於LSM-Like樹實現,因此一次範圍查詢可能會涉及多個分片、多塊快取甚至多個數據儲存檔案;其二是因為HBase中更新操作以及刪除操作實現都很簡單,更新操作並沒有更新

MapReduce程式的過程

問題導讀1、HDFS框架組成是什麼?2、HDFS檔案的讀寫過程是什麼?3、MapReduce框架組成是什麼?4、MapReduce工作原理是什麼?5、什麼是Shuffle階段和Sort階段?

關於python中cv帶中文字元問題(imwrite儲存失敗)

今天在寫一段資料augment程式的時候,裡面用到了cv2.imwrite這個函式發現雖然沒有報錯,程式也執行完了,但是沒有產生相應的圖片。並且在下一段使用cv2.imread讀取圖片的時候也發現讀進來的顯示為None。這是怎麼回事呢。 後來在通過查詢帖子發現,這個可能是因

HBASE系統架構圖以及各部分的功能作用,物理儲存,HBASE定址機制,過程,Region管理,Master工作機制

1.1 hbase內部原理 1.1.1 系統架構 Client  1 包含訪問hbase的介面,client維護著一些cache來加快對hbase的訪問,比如regione的位置資訊。   Zookeeper  1 保證任何時候,叢集中只有一個master&

HDFS資料的過程

1.資料讀取過程 一般的檔案讀取操作包括:open 、read、close等  客戶端讀取資料過程,其中1、3、6步由客戶端發起: 客戶端首先獲取FileSystem的一個例項,這裡就是HDFS對應的例項: ①客戶端呼叫FileSystem例項的open方法,獲得這個

HDFS資料儲存與過程

  InnoDB是在MySQL儲存引擎中第一個完整支援ACID事務的引擎,該引擎之前由Innobase oy公司所開發,後來該公司被Oracle收購。InnoDB是MySQL資料庫中使用最廣泛的儲存引擎,已被許多大型公司所採用如Google、Facebook、YouTube等,如

Ceph中糾刪碼的過程與快取分層

之前一直在關注Ceph讀寫過程與修復,現將之前看到的內容記錄下來。歡迎探討。 讀寫過程 上圖大體可以表示從檔案到儲存在儲存實體上的過程,詳細步驟如下: 1.       RADOS中需要配置Object Size的值,也就是每個Object大小的最大值,一般情況下會設

裝置樹學習之(七)I2C裝置的註冊過程分析

開發板:tiny4412SDK + S702 + 4GB Flash 要移植的核心版本:Linux-4.4.0 (支援device tree) u-boot版本:友善之臂自帶的 U-Boot 2010.12 busybox版本:busy

Linux核心移植 part2:uboot裝置樹--生成過程分析

本文從裝置樹軟體控制相關程式碼進行分析,進而理清裝置樹相關的知識。 先放一個裝置樹在記憶體中的結構圖: 分析來源為$(tree)/lib/fdtdec_test.c 一、資料結構 1.1 檔案頭 每個dtb都包含如下結構的檔案頭,用來表示裝

Linux I2C裝置應用程式

中間驅動中通過呼叫i2c_get_adapter(id)和i2c_put_adapter(id)來獲取和釋放adapter總線上的相應的I2C裝置,通過呼叫adpter的i2c_transfer來進行讀寫通訊。 I2C_dev 就是個典型的例子,I2C_dev為adapter總線上的每一個I2c adapte

S3C6410 SPI全雙工流程分析(原創)

S3C6410 SPI全雙工讀寫流程分析 一、SPI控制器datasheet 2 SPI的所有暫存器都是對映到核心空間的,採用基地址+偏移地址的方式訪問 static volatile void  __iomem *spiregs;                 

golang RWMutex分析

RWMutex:是基於Mutex實現的讀寫互斥鎖,一個goroutine可以持有多個讀鎖或者一個寫鎖,同一時刻只能持有讀鎖或者寫鎖 資料結構設計: type RWMutex struct { w Mutex // 互斥鎖 writ

Linux應用程式訪問字元裝置驅動詳細過程解析

下面先通過一個編寫好的核心驅動模組來體驗以下字元裝置驅動 可以暫時先忽略下面的程式碼實現! memdev.c #include <linux/module.h> #include <linux/fs.h> #include <linux/in

從核心檔案系統看檔案過程

回到頂部系統呼叫作業系統的主要功能是為管理硬體資源和為應用程式開發人員提供良好的環境,但是計算機系統的各種硬體資源是有限的,因此為了保證每一個程序都能安全的執行。處理器設有兩種模式:“使用者模式”與“核心模式”。一些容易發生安全問題的操作都被限制在只有核心模式下才可以執行,例

hbase學習教程(二):HBase容錯性和Hbase使用場景、Hbase過程詳解

HBase容錯性 Write-Ahead-Log(WAL) 該機制用於資料的容錯和恢復: 每個HRegionServer中都有一個HLog物件,HLog是一個實現Write Ahead Log的類,在每次使用者操作寫入MemStore的同時,也會寫一份

hbase 過程

  HBase中的每張表都通過行鍵按照一定的範圍被分割成多個子表(HRegion),預設一個HRegion超過256M就要被分割成兩個,由HRegionServer管理,管理哪些HRegion由HMaster分配。   HRegionServer存取一個子表時,會建立一個HRegion物件,然後對表的每個列

u-boot的nand驅動過程分析

從命令說起,在u-boot輸入下列命令: nand write 40008000 0 20000 命令的意思是將記憶體0x40008000開始的部分寫入nand,從nand地址0開始寫,寫入長度是0x200000回車之後,程式碼如何執行呢?命令的輸入,執行之前都已經分析過了