Linux设备文件系统的起源-2, linux内核2.4引入的devfs

【版权申明】未经博主同意，谢绝转载！（请尊重原创，博主保留追究权） 

Linux设备文件系统的起源-2, linux内核2.4引入的devfs

devfs(设备文件系统)是Linux2.4内核时引入的, 它使得设备驱动程序能自主得管理自己的设备文件(即/dev目录下的设备文件, 在此之前的驱动程序是需要自己手动创建设备文件的. 详情可看上一章).

#include <linux/init.h>
#include <linux/module.h>
#include <linux/fs.h>



static int major = 111;
static char *device_name = "led_drv";

static devfs_handle_t devfs_handle;

static struct file_operations hi3516cv500_led_fops = {
	.owner = THIS_MODULE,
};


int __init led_drv_init(void)
{
	register_chrdev(major, device_name, &hi3516cv500_led_fops);	//向Linux内核注册设备驱动.
	devfs_handle = devfs_register(NULL, device_name, DEVFS_FL_DEFAULT, \ 
								  major, 0, S_IFCHR | S_IWUSR | S_IRUSR, \
								  &hi3516cv500_led_fops, NULL);	//创建设备文件.

	return 0;
}

void __exit led_drv_exit(void)
{
	devfs_unregister(devfs_handle);	//撤销设备文件
	unregister_chrdev(major, "led_drv");	//向Linux内核注销设备驱动.
}

module_init(led_drv_init);
module_exit(led_drv_exit);

MODULE_AUTHOR("yangbkGit");
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("A led driver.");
MODULE_ALIAS("led");

结果:

1. cat /proc/devices
   [命令可以获取到系统中注册的设备，第一列为主设备号，第 2 列为设备名称]
   结果: 可以找到我们insmod安装的驱动

   Character devices:
   111 led_drv

2. ls -l /dev
   [命令可以获取到系统中包含的设备文件，日期的前两列分别给出了主设备号和次设备号]
   结果: 可以找到我们insmod安装的驱动的设备文件.

   crw------- 1 root root 111, 0 Feb 12 14:58 led_drv

   c表示该文件时一个字符设备文件;
   主设备号时111, 次设备号是0;

devfs具有以下优点:

1. 在设备驱动程序注册时(即设备初始化时)会在/dev目录下创建设备文件, 在注销时会删除该设备文件;
2. 设备驱动程序中可以指定设备名, 所有者和权限位, 用户空间程序仍可以修改所有者和权限位;
3. 不再需要为设备程序分配主设备号以及处理次设备号, 可以在程序中给register_chrdev()传递主设备号0, 让Linux内核给我们分配主设备号, 并在devfs_register()函数中指定次设备号;

devfs具有以下缺点:

  在Linux2.6内核中, devfs被认为是过时的方法且最终被淘汰, udev取代了它的位置. Linux VFS内核维护者AI viro指出了几点udev取代devfs的原因: (这里其实有一段话, 但是我们直接说出总结就好了)

1. devfs 所做的工作被确信可以在用户态来完成; (Unix/Linux的接口设计有一句通用的格言“提供机制而不是策略”)

   Linux 设计中强调的一个基本观点是机制和策略的分离。机制是稳定的，而策略是灵活的，机制应该在内核完成，而策略最好在用户空间实现。

2. devfs被加入内核时, 大家期望它的质量可以迎头赶上, 但是随着使用发现了devfs有一些可修复和无法修复的bug, 对于无法修复的bug在相当长一段时间内没有改观, devfs的维护者和作者对其感到失望并停止了维护.