最先獲得突破的是解決了下午的崩潰問題。其實原因很簡單，我聲明了一個unsigned int型指針，但是沒有給它分配空間……

解決了這個問題之后就很簡單了，調用定義在linux/dcache.c文件中的full_name_hash函數對文件名進行hash計算。這里發現了一個很久以來的問題：舉例#include<linux/fs.h>，這個文件夾的根目錄并不是通常所想的/usr/include，而應該是/usr/src/linux/include。to 豬頭：這可能是你編譯失敗的原因。

之后通過ls觀察了full_name_hash的輸出結果，為32位unsigned int，與預想的一樣（這是廢話）。之后要檢驗輸出的結果是否與dcache中hash表中的結果一樣。結果發現這又是多此一舉，這牽涉到了dcache的運行機制（花了近兩個小時搞明白了，汗）。full_name_hash存放的結果位于name.hash中（name是一個qstr結構，qstr.name就是通常使用的unsigned char *name）。而dcache中hash表中使用的是struct list_head *d_hash（之后有個函數名也叫d_hash，不要混淆）。list_head就是我們數據結構中講到的雙向鏈表，不用管它。d_hash的獲得過程就是使用函數d_hash將full_name_hash的結果（也就是name.hash）與其父節點一起再次進行hash運算（算法是否與full_name_hash一樣我就沒有深究了）。這么做的理由是為了允許在不同目錄下能夠存在同名目錄（這樣盡管full_name_hash的結果是一樣的，但是parent值不同，所以不會沖突）。函數d_hash返回的是一個list_head的結構。list_head通過一個名叫list_entry的宏進行訪問。（幸好有source insight啊，不然就累死了……）。全部過程在/usr/src/linux/fs/dcache.c中進行描述。

fist的optype對應的是file數據結構中file_operation結構所描述的一系列函數（其實只是個函數跳轉表，因為這些操作絕大部分情況下都要交給FS完成的）。定義位于<linux/fs.h>

TO DO：解決mkdir的問題。原本是想改進算法使hash計算的結果能夠直接在d_cache中進行查找。現在看來不大可能。還是按照原來的算法進行。接下來要做的是確定mkdir的用法以及相應的嵌入位置。順利的話半天應該可以解決。


感想：第一次使用blog記錄進度。感覺blog的好處除了信息共享之外還能象日記一樣逼著你記下一天的進程。這樣不會在荒廢了一天之后隨便找個理由蒙混過關然后第二天重復無所事事的生活。對我這種人而言很適合。


另外，TO 豬頭：你什么時候才能加進來！

轉載于:https://www.cnblogs.com/acesyp/archive/2005/04/24/144185.html

總結

以上是生活随笔為你收集整理的一天的学习成果：hash输出，dcache工作原理，include的home directory，fist optype的含义...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。