如何手动创建一个设备节点，写出主要命令及参数

Linux下生成驱动设备节点文件的方法有3个：1、手动mknod；2、利用devfs；3、利用udev在刚开始写Linux设备驱动程序的时候，很多时候都是利用mknod命令手动创建设备节点，实际上Linux内核为我们提供了一组函数，可以用来在模块加载的时候自动在/dev目录下创建相应设备节点，并在卸载模块时删除该节点。在2.6.17以前，在/dev目录下生成设备文件很容易，devfs_mk_bdevdevfs_mk_cdevdevfs_mk_symlinkdevfs_mk_dirdevfs_remove这几个是纯devfs的api，2.6.17以前可用，但后来devfs被sysfs+udev的形式取代，同时期sysfs文件系统可以用的api：class_device_create_file，在2.6.26以后也不行了，现在，使用的是device_create ，从2.6.18开始可用struct device *device_create(struct class *class, struct device *parent,dev_t devt, const char *fmt, ...)从2.6.26起又多了一个参数drvdata： the data to be added to the device for callbacks不会用可以给此参数赋NULLstruct device *device_create(struct class *class, struct device *parent,dev_t devt, void *drvdata, const char *fmt, ...) 下面着重讲解第三种方法udev在驱动用加入对udev的支持主要做的就是：在驱动初始化的代码里调用class_create(...)为该设备创建一个class，再为每个设备调用device_create(...)( 在2.6较早的内核中用class_device_create)创建对应的设备。内核中定义的struct class结构体，顾名思义，一个struct class结构体类型变量对应一个类，内核同时提供了class_create(…)函数，可以用它来创建一个类，这个类存放于sysfs下面，一旦创建好了这个类，再调用 device_create(…)函数来在/dev目录下创建相应的设备节点。这样，加载模块的时候，用户空间中的udev会自动响应 device_create(…)函数，去/sysfs下寻找对应的类从而创建设备节点。struct class和class_create(…) 以及device_create(…)都包含在在/include/linux/device.h中，使用的时候一定要包含这个头文件，否则编译器会报错。struct class定义在头文件include/linux/device.h中class_create(…)在/drivers/base/class.c中实现device_create(…)函数在/drivers/base/core.c中实现class_destroy(...),device_destroy(...)也在/drivers/base/core.c中实现调用过程类似如下：static struct class *spidev_class/*-------------------------------------------------------------------------*/ static int __devinit spidev_probe(struct spi_device *spi){....dev =device_create(spidev_class, &spi->dev, spidev->devt,spidev, "spidev%d.%d",spi->master->bus_num, spi->chip_select) ...} static int __devexit spidev_remove(struct spi_device *spi){...... device_destroy(spidev_class, spidev->devt) ..... return 0} static struct spi_driver spidev_spi = {.driver = {.name ="spidev",.owner =THIS_MODULE,},.probe =spidev_probe,.remove =__devexit_p(spidev_remove), }/*-------------------------------------------------------------------------*/ static int __init spidev_init(void){.... spidev_class =class_create(THIS_MODULE, "spidev") if (IS_ERR(spidev_class)) {unregister_chrdev(SPIDEV_MAJOR, spidev_spi.driver.name) return PTR_ERR(spidev_class) }....}module_init(spidev_init)static void __exit spidev_exit(void){...... class_destroy(spidev_class) ......}module_exit(spidev_exit)MODULE_DESCRIPTION("User mode SPI device interface")MODULE_LICENSE("GPL") 下面以一个简单字符设备驱动来展示如何使用这几个函数 #include <linux/module.h>#include <linux/kernel.h>#include <linux/init.h>#include <linux/fs.h>#include <linux/cdev.h>#include <linux/device.h>int HELLO_MAJOR = 0int HELLO_MINOR = 0int NUMBER_OF_DEVICES = 2struct class *my_class//struct cdev cdev//dev_t devnostruct hello_dev {struct device *devdev_t chrdevstruct cdev cdev}static struct hello_dev *my_hello_dev = NULLstruct file_operations hello_fops = { .owner = THIS_MODULE}static int __init hello_init (void){int err = 0struct device *devmy_hello_dev = kzalloc(sizeof(struct hello_dev), GFP_KERNEL)if (NULL == my_hello_dev) {printk("%s kzalloc failed!\n",__func__)return -ENOMEM}devno = MKDEV(HELLO_MAJOR, HELLO_MINOR)if (HELLO_MAJOR)err= register_chrdev_region(my_hello_dev->chrdev, 2, "memdev")else{err = alloc_chrdev_region(&my_hello_dev->chrdev, 0, 2, "memdev")HELLO_MAJOR = MAJOR(devno)} if (err) {printk("%s alloc_chrdev_region failed!\n",__func__)goto alloc_chrdev_err}printk("MAJOR IS %d\n",HELLO_MAJOR)cdev_init(&(my_hello_dev->cdev), &hello_fops)my_hello_dev->cdev.owner = THIS_MODULEerr = cdev_add(&(my_hello_dev->cdev), my_hello_dev->chrdev, 1)if (err) {printk("%s cdev_add failed!\n",__func__)goto cdev_add_err}printk (KERN_INFO "Character driver Registered\n")my_class =class_create(THIS_MODULE,"hello_char_class") //类名为hello_char_classif(IS_ERR(my_class)) {err = PTR_ERR(my_class)printk("%s class_create failed!\n",__func__)goto class_err}dev = device_create(my_class,NULL,my_hello_dev->chrdev,NULL,"memdev%d",0) //设备名为memdevif (IS_ERR(dev)) {err = PTR_ERR(dev)gyro_err("%s device_create failed!\n",__func__)goto device_err}printk("hello module initialization\n")return 0device_err:device_destroy(my_class, my_hello_dev->chrdev)class_err:cdev_del(my_hello_dev->chrdev)cdev_add_err:unregister_chrdev_region(my_hello_dev->chrdev, 1)alloc_chrdev_err:kfree(my_hello_dev)return err} static void __exit hello_exit (void){cdev_del (&(my_hello_dev->cdev))unregister_chrdev_region (my_hello_dev->chrdev,1)device_destroy(my_class, devno)//delete device node under /dev//必须先删除设备，再删除class类class_destroy(my_class)//delete class created by usprintk (KERN_INFO "char driver cleaned up\n")} module_init (hello_init)module_exit (hello_exit)MODULE_LICENSE ("GPL")这样，模块加载后，就能在/dev目录下找到memdev这个设备节点了。 例2:内核中的drivers/i2c/i2c-dev.c在i2cdev_attach_adapter中调用device_create(i2c_dev_class, &adap->dev, MKDEV(I2C_MAJOR, adap->nr), NULL, "i2c-%d", adap->nr)这样在dev目录就产生i2c-0 或i2c-1节点 接下来就是udev应用，udev是应用层的东西，udev需要内核sysfs和tmpfs的支持，sysfs为udev提供设备入口和uevent通道，tmpfs为udev设备文件提供存放空间udev的源码可以在去相关网站下载，然后就是对其在运行环境下的移植，指定交叉编译环境，修改Makefile下的CROSS_COMPILE，如为mipsel-linux-，DESTDIR=xxx，或直接make CROSS_COMPILE=mipsel-linux-,DESTDIR=xxx 并install把主要生成的udevd、udevstart拷贝rootfs下的/sbin/目录内，udev的配置文件udev.conf和rules.d下的rules文件拷贝到rootfs下的/etc/目录内并在rootfs/etc/init.d/rcS中添加以下几行：echo “Starting udevd...”/sbin/udevd --daemon/sbin/udevstart（原rcS内容如下：# mount filesystems/bin/mount -t proc /proc /proc/bin/mount -t sysfs sysfs /sys/bin/mount -t tmpfs tmpfs /dev# create necessary devices/bin/mknod /dev/null c 1 3/bin/mkdir /dev/pts/bin/mount -t devpts devpts /dev/pts/bin/mknod /dev/audio c 14 4/bin/mknod /dev/ts c 10 16）这样当系统启动后，udevd和udevstart就会解析配置文件，并自动在/dev下创建设备节点文件

udev的rules定制和调试

在定制项目中，对外设的热插拔的管理基本都在udev/systemd-udev来管理。这里没有对基本的udev使用/rules书写进行介绍。

1. udev的rules可能的位置

/lib/udev/rules.d -- udev默认/预置的rules

/etc/udev/rules.d/ -- 定制的rules， 优先级高于/lib/udev/rules.d，官方建议客户写的rules都放这里

至于放在哪个位置，自己决定就好，既然你在修改系统就应该知道你在做什么

2. 定制自己的rules

定制热插拔的事件，具体到rules就是：

  1）过滤到正确的udev事件。

  2）指定执行的动作，rules里的“RUN”，通常是脚本（毕竟要完成一个功能，绝大多数场景都不是一个命令能搞定的）

3.到这里就要设计到rules的调试了

  1）如何知道要过滤的是条件？

  2）如何将必要的参数传递给RUN执行的脚本？

方法1:

udevadm monitor -p

-- 监测所以的kernel/udevd的热插拔事件， -p选项很有必要，打印出本次热插拔事件的一些属性

这里就是比较设备插入和拔出时的事件属性的不同，可作为过滤的条件

比如：

rules文件对于规则：

到这里很多时候就能满足要求了，如果还有解决不里的场景，就要进一步修改过滤条件。

man udev里会有绝大部分的关键字的信息（想全部的就只能去撸源码）。

方法2:

通过在RUN指定的脚本里传递参数，来找到设备存在和不存在的属性差异。

比如：

参考信息：

a）、udev 规则的匹配键

ACTION： 事件 (uevent) 的行为，例如：add( 添加设备 )、remove( 删除设备 )。

KERNEL： 内核设备名称，例如：sda, cdrom。

DEVPATH：　  设备的 devpath 路径。

SUBSYSTEM： 设备的子系统名称，例如：sda 的子系统为 block。

BUS： 设备在 devpath 里的总线名称，例如：usb。

DRIVER： 设备在 devpath 里的设备驱动名称，例如：ide-cdrom。

ID： 　 设备在 devpath 里的识别号。

SYSFS{filename}： 设备的 devpath 路径下，设备的属性文件“filename”里的内容。

　例如：SYSFS{model}==“ST936701SS”表示：如果设备的型号为 ST936701SS，则该设备匹配该 匹配键。

　在一条规则中，可以设定最多五条 SYSFS 的 匹配键。

ENV{key}： 　 环境变量。在一条规则中，可以设定最多五条环境变量的 匹配键。

PROGRAM：调用外部命令。

RESULT：   外部命令 PROGRAM 的返回结果。

b）、udev 的重要赋值键

NAME：　在 /dev下产生的设备文件名。只有第一次对某个设备的 NAME 的赋值行为生效，之后匹配的规则再对该设备的 NAME 赋值行为将被忽略。如果没有任何规则对设备的 NAME 赋值，udev 将使用内核设备名称来产生设备文件。

SYMLINK：　 为 /dev/下的设备文件产生符号链接。由于 udev 只能为某个设备产生一个设备文件，所以为了不覆盖系统默认的 udev 规则所产生的文件，推荐使用符号链接。

OWNER, GROUP, MODE：为设备设定权限。

ENV{key}：　导入一个环境变量。

c）、udev 的值和可调用的替换 *** 作符

Linux 用户可以随意地定制 udev 规则文件的值。例如：my_root_disk, my_printer。同时也可以引用下面的替换 *** 作符：

$kernel, %k：设备的内核设备名称，例如：sda、cdrom。

$number, %n：　 设备的内核号码，例如：sda3 的内核号码是 3。

$devpath, %p：　设备的 devpath路径。

$id, %b：设备在 devpath里的 ID 号。

$sysfs{file}, %s{file}：  设备的 sysfs里 file 的内容。其实就是设备的属性值。

$env{key}, %E{key}：　一个环境变量的值。

$major, %M：设备的 major 号。

$minor %m：设备的 minor 号。

$result, %c：PROGRAM 返回的结果。

$parent, %P：    父设备的设备文件名。

$root, %r：  udev_root的值，默认是 /dev/。

$tempnode, %N：临时设备名。

%%：符号 % 本身。

$$：　符号 $ 本身。

对比一下和man里的差别，$sysfs{file}，这个在实际解决问题的时候是很有用的。

这种方法适合调试系统启动的时候对rules的调试，这个过程中是没得udevadmin monitor使用的。（当然，可以尝试自己写一个systemd启动服务，这就涉及到启动的时机、关联、影响，实际 *** 作会比预想的复杂）

这里提两个点：

1. env - 可以是udev事件里的属性（-p打印的）

2. $sysfs{file}, 这里的file就是在系统/sys目录下对应的节点下的文件，有些情况下只能在sysfs的file的内存才能准确区分事件。

---