塊裝置一次傳輸乙個setor，使用者態卻沒有介面使用這一功能。而把塊裝置模擬成字元裝置，使用者態就可以用普通讀寫的方式來訪問塊裝置，比如將dd作用於塊裝置（複製mbr之類的）。模擬的實現很容易想象，比如對於讀操作，將對位元組的需求轉換為對sector的需求，讀入需要的sector，再將要求的位元組送出去。寫稍微複雜一點。總體來看，跟os裡檔案系統中的某部分功能類似。
而一提到字元裝置，馬上就想起了linux字元裝置框架，cdev神馬的。之前一直以為將塊裝置模擬為字元裝置有額外的**：做乙個字元裝置驅動來適配對塊裝置的操作。後來發現平時dd的裝置檔案就是乙個塊裝置檔案。那read,write請求都走到**去了呢？
vfs層中open流程有一步是設定file的ops。這個ops跳轉表是從inode得到的，在open時將其賦於file的成員，以後引用file就可以進行檔案操作；如果ops->open不為空，還會順便呼叫之。開啟乙個字元裝置(c)時，字元裝置檔案inode裡的ops為def_chr_fops，隻裡僅定義了open操作(chrdev_open)。註冊乙個字元裝置驅動就是將驅動提供的ops跳轉表與某段裝置號相關聯（實際上是將cdev與某段裝置號相關聯，fops作為cdev的乙個成員）。而chrdev_open則進行相反的操作：查詢給定裝置號是否fops與之關聯。如果有，則將這個fops賦給file的相關字段（覆蓋了def_chr_fops），新的ops->open不為空的話，呼叫之（給驅動乙個初始化機會；這已經是第三次open了）。以後對這個檔案的操作則由驅動提供了ops跳轉表來支撐。
如果直接開啟乙個塊裝置檔案(b)，vfs給file的ops賦值時，從inode得到的是def_blk_fops。def_chr_fops只定義了open方法，這個open方法會陷到字元裝置系統裡。而def_blk_fops整定義了一整套方法。def_chr_fops只起過渡作用，它的open方法要去尋找硬體驅動的支撐；def_blk_fops則直接提供了所有支援。至於對硬體信賴，好像被page cache遮蔽掉了
。
C 引數傳遞時到底發生了什麼
1 引用型別的變數只包含物件所在的記憶體位址，將要複製的是記憶體位址而不是物件本身，所以對底層物件的修改會保留。unsafeclassprogram fixed int pid mye.id 值為 uint pid uint pid testmethod mye fixed int pid mye....
點選列印按鈕時發生了什麼？
在windir system32 spool printer中生成了2個臨時檔案。shd和 spl。有可能還有 tmp檔案。各個檔案的作用如下 1 spl 檔案是實際的後台列印 列印作業 檔案。2 tmp 檔案是通常與 lpr 列印作業相關聯。3 shd 檔案提供有關哪台印表機列印作業傳送到或從其列...
呼叫malloc時發生了什麼（3） 缺頁中斷
例如 使用者態通過brk申請了一塊記憶體，後續訪問這塊記憶體的0x00007f88f16a4690這塊位址會發生什麼？首先，x64核心是4級頁表，根據x64對線性位址的劃分，可以計算出0x00007f88f16a4690這位址的pgd索引是 255，pud索引是 35，pmd索引是 395，pte索...