一天的学习成果：hash输出，dcache工作原理，include的home directory，fist optype的含义...

最先获得突破的是解决了下午的崩溃问题。其实原因很简单，我声明了一个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