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

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

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

fist的optype對應(yīng)的是file數(shù)據(jù)結(jié)構(gòu)中file_operation結(jié)構(gòu)所描述的一系列函數(shù)（其實只是個函數(shù)跳轉(zhuǎn)表，因為這些操作絕大部分情況下都要交給FS完成的）。定義位于<linux/fs.h>

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


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


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

轉(zhuǎn)載于:https://www.cnblogs.com/acesyp/archive/2005/04/24/144185.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。