引入symlink以及对lookup的改进

[schulice]

需求

• 实现symlink的相关接口，方便其他模块使用。
• 改进lookup，主要是1. 改进dcache的使用方式和2. 确保lookup的一致性。
• 更改部分dcache的实现，涉及 #669

可能的实现方法

Symlink

如何解析带symlink的路径

行为来自linux kernel，自上而下解析

• inside the path - always follow.
• in the last component in creation/removal/renaming - never follow.
• if LOOKUP_FOLLOW passed - follow.
• if the pathname has trailing slashes - follow.
• otherwise - don't follow.

在inode中增删改查

• 向inode接口中添加symlink，get_link和readlink。

在vfs中

• 实现do_symlink()等
• lookup使用堆栈存储多的symlink剩余路径，可以放宽symlink的上限，8->40
• 小堆栈在nameidata中(<=2)，大堆栈在页缓存中。

Lookup

在 #669 中对lookup有一定的更改，但是（在这里我用inode-walk表示直接对inode的访问，属于私设）

1. 各种lookup的耦合度太高。
2. 在lookup的过程中没有增加路径上成员的引用计数，路径可能在lookup过程中发生更改。
3. 同时，rename过程会对lookup过程产生影响，可能需要引入seqlock来快速更新（即发生rename时更新dentry的seqlock，使得lookup过程读取失败再次尝试）。

具体的实现可以部分参考linux kernel doc中的lookup。

是否引入RCU-walk

这应当需要另一个issue了。 它大部分的操作基于ref-walk，在实现完善的ref-walk后再讨论较为合适。 （而且这个issue回避了rcu_lock）

需要引入的新功能

1. seqlock - 顺序锁，类似写优先的读写锁，用于rename等行为更改目录时（此时作为rename_lock等），确保lookup的一致性（此时lookup失败并重试）。
2. i_rwsem - 读写信号量（可选，或使用别的方法），在dcache的查找中被持有，防止其他进程修改path上的component。
3. dentry - dcache的组成部分，全局关联vfs，管理inode在内存中的缓存，加快lookup的访问速度（如 #669 中的部分实现）。
4. nameidata - 用于管理查找过程的结构体（可选），持有当前的查找过程的一些所需对象。

需要更改的功能（部分）

1. lookup - 分离inode-walk和ref-walk（即将对dentry的操作和inode的操作分离）。
2. rename等 - 在dcache中和inode中同时进行更新。
3. inode - 添加一些seqlock

与现有sysfs等的兼容性

1. 在具体的fs中添加flag来判断是否在相应的文件系统启用dcache。在 #669 的实现中dcache暂时挂在各个文件系统的实例下，可能不方便slab的内存分配和管理。（自然，可以安排一个地址空间对象让新建的dcache注册上去，再让该对象与内存分配器交互。但这个情况下各个fs实例都持有一个cache的lru链表，释放时的策略需要再设计）。
2. symlink等的inode接口的添加可能会使得一些sysfs的实现得到改进。
3. 在不启用dcache的文件系统下，lookup回退到inode-walk。
4. 向inode添加的锁可能需要更改部分行为。

与Mount的兼容性

1. 可能添加mount_lock(type: seqlock)来安全的越过挂载点（即在unmount等行为同时发生时使得lookup失效，现在master还未实现unmount）
2. 需要一个在dcache的lookup过程中知晓跨越mount的方法。

关于 #669

1. dentry是否需要区分use和unuse，即是正在使用的dentry不需要加入到LRU链表中，LRU-linklist中只有引用计数为0的dentry（回调或者别的方式添加），用于回收内存。
2. dcache的实现是否应当不为特定的文件系统而建立，放在vfs层中，不与具体的文件系统强关联。
3. 如上的lookup中的说明。

总结

这个issue涉及到vfs中的并发安全，新的锁，dcache也同内存和slab分配器有关。这两者的行为关联较强，故合并一个issue来写。 参考的资料主要是linux kernel doc中的vfs，lookup，slab等篇目和linux kernel code。 当然该issue落地时应当会遇到不少的麻烦，需要对语言特性和现有api进行兼容，还需要一些修改。