Linux 内核文件系统与设备操作流程分析(1) 本笔记对 Linux kernel 的文件系统操作以及设备操作进行了分析，主要是针对 ext3 文件系统的 open 流程的分析，目的是为了解答心中的几个疑问：1、一个文件的操作流程，系统是如何把 strUCt file 与 struct dentry 以及 struct inode 结合起来的？2、文件与设备驱动都是对 VFS(Virtual File System) 抽象出来的 struct file 进行操作的，那么系统是如何区分的？在哪里开始区分的？3、linux 内核中没有类 Unix VFS(Virtual File System) 提供的 struct vnode 结构，那么具体的文件操作是如何与实际文件系统的操作挂钩的？4、超级块(super block)在文件与设备驱动操作中起到的作用？5、在以前的尝试中对 struct file 做手脚为什么影响不到全局？6、在文件系统内核有几个函数操作集？有何不同？分别是在什么时候赋值？注：此文档是根据当时的分析过程记录的，分析顺序也就没有再更改过， 每个人读内核源码的思路不同，或者说目的不同，流程自然也就不同。 所以在别人看来我所记录的可能比较凌乱。如果真是这样，那我只能 说句抱歉，因为我并不打算再修改记录顺序。最后还是那句话，如果 您在阅读本文时发现了错误，还望得到您的指正。我们知道在 linux kernel 中，如果想操作一个文件，首先要通过 filp_open()这个 kernel api 来打开这个文件，那么我们就从这里入手分析。可以看到filp_open() 函数只是个简单封状，具体实现是 do_filp_open() 函数，函数本身先通过 open_namei() 函数得到一个 fd 对应的 struct nameidata 结构。最后使用 nameidata_to_filp() 函数返回一个 struct file 结构。static struct file *do_filp_open(int dfd, const char *filename, int flags, int mode){ int namei_flags, error; struct nameidata nd; namei_flags = flags; if ((namei_flags+1) & O_ACCMODE) namei_flags++; // // 这个函数调用 path_lookup_xxx() 等函数根据路径名称 // 返回一个 struct nameidata 结构。这个函数完成了很多
