BaikalHU

为了管理磁盘空间，文件系统需要知道哪些block是空闲的。Omfs使用bitmap来达到这个目的。Bitmap的每一个bit对应磁盘上的一个block，当对应的block被分配后，bitmap中的相应bit会被设置为1。这个是很经典也很清晰的一个设计，下面我们看看omfs的具体做法：在上面新建的文件系统中新建一个文件aaaa：Touch aaaals -alitotal 4

do_path_lookup是文件系统中最基本的函数，也是非常重要的，里面各种情况，各种goto，总之各种坑爹。。       没能把所有的goto都理清，只看了标准情况下的路径查找，但主要的关键点都是一样的，弄清了关键点，心中对文件系统的路径名查找就有了概念。不管绝对路径名，相对路径名，还是带符号链接的，又有什么质的区别呢？       do_path_lookup分为两步：

属性文件的建立和目录的建立相差不大,因为不管目录还是普通文件，都由一个sysfs_dirent代表sysfs_create_file-->sysfs_add_file-->sysfs_add_file_modeintsysfs_add_file_mode(struct sysfs_dirent *dir_sd,conststruct attribute *attr, int type,

前面分析了这么多，是因为设备模型和文件系统的联系很紧密，了解sysfs是为了更好的理解设备模型。        在分析sysfs的时候，我们也看到了sysfs_dirent与kobject的紧密联系。这一次我们分析下kobject kest和ktype。在vfs层，sysfs的目录和属性文件都有对应的inode和dentry；而在sysfs中，不管目录还是文件，都用统一的sysfs_diren

在分析设备模型的bus之前，我们看一下初始化的过程，很有意思：     start_kernel-->rest_init-->kernel_init-->do_basic_setup     在do_basic_setup中有个usermodehelper_init有意思，凭感觉，这个函数与kobject_uevent有联系，kobject_uevent做什么的，就是内核空间来通知用户空间

sysfs的属性文件的读写，我们先看下open，open系统调用最终会调用sysfs_open_file       struct sysfs_dirent *attr_sd = file->f_path.dentry->d_fsdata;    //获取sysfs_dirent结构struct kobject *kobj = attr_sd->s_parent->s_dir.kobj;

在vfs_caches_init中有三个重要的hashtable：mount_hashtabledentry_hashtable inode_hashtableHashtable有什么作用？主要的查找的效率很高，vfs层用这三个就是为了提高查找效率。另外一个，inode和dentry是内存中的数据，而数据的来源是硬盘，如果我们获得了inode和dentry数据，加到hashtable中，方

分析完了bus，接下来分析device：      同样在driver_init-->devices_initint __init devices_init(void){ devices_kset = kset_create_and_add("devices", &device_uevent_ops, NULL); if (!devices_kset) return -ENO

看完了bus device和driver,终于到了设备模型上层架构的最后一个单元:class.class的初始化同样是在driver_init下:      driver_init-->classes_initint __init classes_init(void){ class_kset = kset_create_and_add("class", NULL, NULL); if

分析文件系统后,再分析设备模型,从而自然的理解了sysfs和设备模型的关系.既然linux2.6引入了设备模型和sysfs,那肯定是比之前更为先进的.下面要分析下内核中如何利用设备模型去管理设备的,在内核的driver目录下有好多子目录,比如iic spi pci input usb这些子系统的框架,这些框架都是在设备模型的模型之上再去抽象的.我们仅以platform这种虚拟的总线类型和rtc这种

对sysfs和设备模型有了解的都会知道sysfs实际是为了将设备模型导出到用户空间的一个内存文件系统。       设备模型的关键结构体kobject会组成设备模型的树形结构，而sysfs的关键结构体sysfs_dirent也是类似的树形的结构，vfs中的dentry同样是类似的树形结构。       sysfs目录文件的创建都是由设备模型的上层构件(bus device driver c

在上一次分析rootfs的安装时，其实是不准确的，应该称为安装根文件系统。        安装根文件系统分为两个阶段：        1、内核安装特殊rootfs文件系统，该文件系统仅提供一个作为初始安装点的空目录。        2、内核在空目录上安装实际根文件系统。比如pc上的ext4，比如嵌入式中用到的各种flash的根文件系统。        这一次分析sysfs，发现sy

文件系统是linux内核的重要组成部分，涉及到vfs、块IO层的调度机制，块设备驱动以及具体文件系统所采用的数据结构。所使用linux内核版本是2.6.34.1。 以fs/omfs为例，主要学习vfs的实现，omfs的硬盘布局，它所采用的数据结构为何能够优化MPEG文件系统。Omfs文件系统的具体文件读写又是如何实现的。 OMFS：Optimized MPEG Filesystem

Omfs的普通文件的创建删除与目录创建删除的动作非常类似，下面仅仅描述一下： 在omfs_create处下断点：Breakpoint 3, omfs_create (dir=0xdde13c20, dentry=0xdf6f6440, mode=33188, nd=0xddbe1eb8) at fs/omfs/dir.c:304 函数调用堆栈如下：#0  omfs_cr

在omfs_rename中下断点：Breakpoint 4, omfs_rename (old_dir=0xddf2cca8, old_dentry=0xdde57330,     new_dir=0xddf2cca8, new_dentry=0xddf2f220) at fs/omfs/dir.c:392Touch   aaaaMv  aaaa  bbbb 函数堆栈如下：

为了研究omfs文件系统是如何进行文件的write操作，我在应用层写了个小程序：#include #include #include #include #include #include #include  Void main(){         Int I;         Char w[16384];         Int fd;

Omfs文件目录的结构是通过对name做hash来实现的： 定义inode_operations结构体，const struct inode_operations omfs_dir_inops = {         .lookup = omfs_lookup,         .mkdir = omfs_mkdir,         .rename = omfs_rena

因为linux支持模块机制，所以我们可以将文件系统编译为模块，所以文件系统系统类型的注册的注册有多种方式：要么已经包含在内核映像中，要么作为一个模块被动态加载。我们关注的重点是rootfs和sysfs，他们其实在系统初始化的时候就注册并安装好了，没有rootfs，linux就没法玩了。以rootfs的注册为例，来分析一下文件系统类型的注册：        在start_kernel-->vfs

在《linux文件系统的系统分析--(一)文件系统类型的注册》我们以rootfs为例分析了文件系统是如何注册的，接着我们就分析rootfs的安装。         在mnt_init-->init_mount_tree:static void __init init_mount_tree(void){ struct vfsmount *mnt; struct mnt_namesp

在看设备模型的时候，对sysfs、devtmpfs有一定了解，也分析过linux下的一个简单的文件系统：omfs。但当时的分析比较散，现在觉得还是得花时间再系统的整理一下为好。因为目前对linux的内存管理还不熟悉，关于vfs中高速缓存的部分暂且略过。这次开篇，准备按照：根文件系统挂载和“/”；文件系统的挂载，sysfs的分析（基于内存的fs和基于磁盘的fs还是有不少差距的），然后在这个基础上再分

linux的虚拟文件系统层的特点在于把很多不同种类文件系统的共同信息放入内核；可以通过vfs的转换来利用linux所支持挂载的实际文件系统。实际上，因为有了vfs，也可以较为方便的按照vfs的一些接口将文件系统移植过来，比如win下的ntfs和fat32就是如此。在open read等系统调用之后就是到vfs_read 等式样的函数，在vfs层做些处理后，再根据当前操作的路径所挂载在哪个文件系统下

从文件系统写到设备模型,写的很舒畅,写的过程中自己重新做了整理思考,很有收获.          那我之所以将文件系统和设备模型放在一起写,因为linux的哲学就是一切都是文件,所以文件系统和设备模型是分不开的,单单理解设备模型还是不充分的,理解了文件系统后,再看设备模型就会有不一样的感受.          王阳明说"知行合一",做了这么多的理论上的分析后,就需要找块板子来实践,验证和加