linux设备管理-dev目录下创建和寻找某一设备文件

这是一篇网上找到的文章分析的很精彩，这篇文章的分析基于网络高手文章中没有介绍的方面。

如果有什么不对的地方，请指正。

谢谢

file_operations流程跟踪

术语

描述符：其实就是结构体

在linux可以把设备看作文件并提供了和文件一样的统一的访问接口，相信大家已经有了一

点的了解，其底层对设备的不同操作主要是由file_operations描述符来控制，其封装了各

种设备的操作方法，如：open/read/write/ioctl等等。

linux中每个文件或目录都对一个名为inode的结构体，其中有一个字段i_fop就是存储文件

的操作方法file_operations实例对象。以下我们将对文件的file_operations如何赋值给

inode->i_fop进行一个简单的跟踪。

linux中，支持很多的文件系统，每个文件系统使用之前都必须要先注册，其注册的过程大

体一致，以下我们将以ext3文件系统为例跟踪file_operations的注册过程。

================================================================================

1，每一种文件系统都有自己的type，在启动时的时候有boot的参数传递告知，最后在mount的

时候根据参数确定那种文件系统。

2，在这里使用的是ext3的文件系统。其实其他的文件系统也有相应的操作。最后完成的就是

调用getsb来完成填充superblock的相关成员变量。以后的基本操作找到相应的操作函数。

================================================================================

在文件系统的初始化阶段调用register_filesystem(&ext3_fs_type)函数将以下结构：

static struct file_system_type ext3_fs_type = {

.owner   = THIS_MODULE,

.name   = "ext3",

.get_sb  = ext3_get_sb,

.kill_sb  = kill_block_super,

.fs_flags = FS_REQUIRES_DEV,

};

注册到全局链表file_systems(fs/filesystems.c)中。

其中函数指针get_sb在超级块全局链表super_blocks(fs/super.c)中查找文件系统对应的超级

块描述符并返回，如果没有则创建新的描述符。

当get_sb函数指针被调用，触发ext3_fill_super(fs/ext3/super.c其为get_sb参数之一的函数

指针)函数调用ext3_iget返回超级块所对应的文件系统的根目录的inode，并根据inode->i_mode

来判断文件类型赋予相应的操作，源代码(fs/ext3/inode.c)如下：

================================================================================

1，如何从path找到相应的inode这是关键

假设 app中使用了int fd = open（“/dev/ttyS0”，777）；这样的怎么在内核找到相应的inode并且把

相关的inode返回给相应的调用程序？

int devtmpfs_create_node(struct device *dev)这个函数是内核调用的，在dev目录下建立相应的

设备节点名。这个函数的调用关系介绍一下，一面突然看着有点陌生的感觉。

int device_add(struct device *dev)

 |

 devtmpfs_create_node(dev);

  |

  err = vfs_mknod(nd.path.dentry->d_inode,dentry, mode, dev->devt);

device_add调用和会在注册设备和设备的相关信息，同时在dev目录下创建相应的设备节点。

下面来看看这个函数在涉及到本文相关内容的部分：

if (!nodename)

  return -ENOMEM;

 if (mode == 0)

  mode = 0600;

 if (is_blockdev(dev))

  mode |= S_IFBLK;

 else

  mode |= S_IFCHR;

  

初始化mode。在今后的函数vfsmknode中会使用。确定到底是那种文件类型，匹配相应的函数来完成

file_operation。请查看原来的分析即

void init_special_inode(struct inode *inode, umode_t mode, dev_t rdev)

这个函数的调用关系其实也很复杂，关键在于不同的文件系统类型有自己的mknode方法。

以上代码表示，其实在节点创建的时候就已经确定了设备节点类型了。如果是char字符类型的

设备，那么相应的操作就是下面提到的def_chr_fops。以此类推，其他的类型设备相应的操作。

2，方向的问题。用户主动调用mknode和内核初始化的时候自己创建设备。

 （a）如果是用户在命令行执行 #mknode就会找到以下函数init_special_inode。这函数其实是

 相关的文件系统的mknode函数。

 （b）如果是内核初始化的时候调用的，那么就是上述devtmpfs_create_node。这个函数也会在

 文件系统的pathlook，dolook，等VFS层的函数中创建并且初始化inode。其实任何文件包括

 设备，在linux中都是以文件来对待。区分文件的标识就是inode。

3，在内核中要打开一个文件，首先应该找到这个文件，而查找文件的过程在vfs里面是由do_path_lookup

或者path_lookup_open函数来完成的，关于文件路径查找就不分析了。层次太多设计的内容太杂。

这两个函数将用户传进来的字符串表示的文件路径转换成一个dentry结构，并建立好相应的inode和file结构，

将指向file的描述符返回用户。用户随后通过文件描述符，来访问这些数据结构。

有了以上的了解最后来看看假设我们内核初始化的时候注册了设备ttyS0这样的一个device。

open就会找到相应的inode和file operations。

================================================================================

if (S_ISREG(inode->i_mode)) {

inode->i_op = &ext3_file_inode_operations;

inode->i_fop = &ext3_file_operations;

ext3_set_aops(inode);

} else if (S_ISDIR(inode->i_mode)) {

inode->i_op = &ext3_dir_inode_operations;

inode->i_fop = &ext3_dir_operations;

} else if (S_ISLNK(inode->i_mode)) {

if (ext3_inode_is_fast_symlink(inode)) {

inode->i_op = &ext3_fast_symlink_inode_operations;

nd_terminate_link(ei->i_data, inode->i_size,

sizeof(ei->i_data) - 1);

} else {

inode->i_op = &ext3_symlink_inode_operations;

ext3_set_aops(inode);

}

} else {

inode->i_op = &ext3_special_inode_operations;

if (raw_inode->i_block[0])

init_special_inode(inode, inode->i_mode,

old_decode_dev(le32_to_cpu(raw_inode->i_block[0])));

else

init_special_inode(inode, inode->i_mode,

new_decode_dev(le32_to_cpu(raw_inode->i_block[1])));

}

在此，我主要讲解对init_special_inode的跟踪，其他函数希望感兴趣的读者自己跟踪。

在对 init_special_inode进行跟踪之前先来说明一下linux的文件路径名查找，当要对

某个索引节点进行处理时，代码首先检查路径名中与第一个名字匹配的目录项，以获得

相应的索引节点。然后，从磁盘读出包含那个索引节点的目录文件，并检查与第二个名

字匹配的目录项，以获得相应的索引节点。对于包含在路径中的每个名字，这个过程反

复执行。那么，当要创建新文件(创建新inode)的时，系统调用其父inode的方法来创建

子inode的。

顾名思义，init_special_inode函数的作用就是初始化特殊的inode，先不多说，看下

面的源码(fs/inode.c)：

void init_special_inode(struct inode *inode, umode_t mode, dev_t rdev)

{

inode->i_mode = mode;

if (S_ISCHR(mode)) {

inode->i_fop = &def_chr_fops;

inode->i_rdev = rdev;

} else if (S_ISBLK(mode)) {

inode->i_fop = &def_blk_fops;

inode->i_rdev = rdev;

} else if (S_ISFIFO(mode))

inode->i_fop = &def_fifo_fops;

else if (S_ISSOCK(mode))

inode->i_fop = &bad_sock_fops;

else

printk(KERN_DEBUG "init_special_inode: bogus i_mode (%o) for"

" inode %s:%lu/n", mode, inode->i_sb->s_id,

inode->i_ino);

}

==================================================================================

在这里一定要介绍一下内核的版本问题，其实上面的文章分析中也涉及很多概念，在2.6.28

的内核中是没有的，比如：devtmpfs。

但是cdev_map这个结构确实是在28的内核中存在，软件管理方式差不多。

==================================================================================

根据上面代码可以得出，init_special_inode对字符设备文件、块设备文件、管道文件、网

络设备文件进行处理，分别赋予inode中的file_operations变量def_chr_fops/def_blk_fops/

def_fifo_fops/bad_sock_fops。

def_chr_fops，fs/char_dev.c文件中的全局变量，源码如下：

const struct file_operations def_chr_fops = {

.open = chrdev_open,

};

chrdev_open，定义在同文件下，其调用了kobj_lookup函数在cdev_map链表中查找对应的

struct kobj_map对象。

现在我们反过来看驱动，在fs/char_dev.c文件中维护了一个struct kobj_map类型的链表cdev_map，

当注册字符设备时file_operations对象被添加到cdev描述符中，添加设备的时候调用kobj_map(

drivers/base/map.c)其最后一个参数为void×类型，传递cdev对象给kobj_map对象。

以上只是一个简单的对file_operations描述符的跟踪，基本上描述了字符设备的这一过程，由于

时间的关系以上的细节描述得不是很详细，而且也没有完全跟踪，希望有兴趣的读者能够自己跟踪。

(注：以上文章仅供参考。由于水平有限，如有问题还请谅解。

基于2.6.32的内核)。

======================================================================

相关介绍在网上很多。也很精彩，由于在查看alsa的内核初始化。

声卡的设备的注册使用了相关的概念，结合以前看过的分析稍作整理。

======================================================================