input 子系统的分析与学习（一）

依然不明白struct device 中的parent是什么意思？

最近在写一个光感传感器设备的驱动。不知为何上层的接口是通过input设备实现的。

其实我们自己也可以讲某一个输入设备 如传感器等写为一个字符设备，但是那样的话，我们需要自己实现open\read\write等方法，需要自己实现阻塞。但是通过实现成一个input设备，我们可以把注意力集中到input设备要汇报的事件上面，其他的工作系统已经帮我们完成了。

经过研究，input设备提供给我们的便利 就是它剥离了设备、设备产生的事件、事件的处理 这三者之间的逻辑。

三者的关系本来如下： 设备 ------- >事件----------> 事件的处理-------->上层应用。 其中设备驱动程序负责产生事件，产生的事件由 事件的handler处理，通常handler处理后，再向用户态发送消息，也就说与用户态的交互都有handler完成。设备驱动程序只负责检测并产生事件，产生事件后调用input_event 函数汇报事件。 然后，对于每一个input_dev，都有相应的handler负责处理。 input_dev与handler之间是独立的，也就是说一个input_dev 提交的 事件，会由这个设备上注册的每个handler都进行处理，而一个handler可以注册给多个设备。

 

input_dev和handler之间的挂钩是通过input_attach_handler函数来实现的，在这个函数中有很严格的匹配条件。内核中实现了evdev_handler和evbug_handler，这两个handler因为限制条件很宽松，所以可以挂接到所有的input_dev。 其中，evbug_handler用于打印消息，相当于是一个调试器，每当input_dev提交事件的时候，事件提交给evbug_handler处理时，evbug_handler都会把事件相关的消息打印出来。

evdev_handler是用于与用户态交互的，evdev_handler中实现了一系列函数结构体，如下：

 

static struct input_handler evdev_handler = {.event= evdev_event,.connect= evdev_connect,.disconnect= evdev_disconnect,.fops= &evdev_fops,.minor= EVDEV_MINOR_BASE,.name= "evdev",.id_table= evdev_ids,};

static const struct file_operations evdev_fops = {.owner= THIS_MODULE,.read= evdev_read,.write= evdev_write,.poll= evdev_poll,.open= evdev_open,.release= evdev_release,.unlocked_ioctl= evdev_ioctl,#ifdef CONFIG_COMPAT.compat_ioctl= evdev_ioctl_compat,#endif.fasync= evdev_fasync,.flush= evdev_flush};

 

 在evdev_handler中实现了connect、disconne函数等，分别实现handler与input_dev的挂接。其中，evdev_fops实现了完整的文件打开、读写等操作。值得重点一提。

 

首先，在input_init函数中， 有：  err = register_chrdev(INPUT_MAJOR, "input", &input_fops); 其中，input_fops中有：

static int input_open_file(struct inode *inode, struct file *file){struct input_handler *handler;const struct file_operations *old_fops, *new_fops = NULL;int err;lock_kernel();/* No load-on-demand here? */handler = input_table[iminor(inode) >> 5];if (!handler || !(new_fops = fops_get(handler->fops))) {err = -ENODEV;goto out;}/* * That's _really_ odd. Usually NULL ->open means "nothing special", * not "no device". Oh, well... */if (!new_fops->open) {fops_put(new_fops);err = -ENODEV;goto out;}old_fops = file->f_op;file->f_op = new_fops;err = new_fops->open(inode, file);if (err) {fops_put(file->f_op);file->f_op = fops_get(old_fops);}fops_put(old_fops);out:unlock_kernel();return err;}

 

也就是说，当我们通过open  /dev/input/ 这个目录下的设备时，都会调用input_open_file这个函数。因为通过register_chrdev这种方法注册的函数体 对于所有的主设备号是INPUT_MAJOR的设备都是通用的。然后，在这个input_open_file中，通过这个 handler = input_table[iminor(inode) >> 5]; 可以得到evdev_handler。这里之所以得到的handler是evdev_handler 而不是其他的handler，是因为其他的handler都没有实现fops函数，内核在handler_register函数中，可以实现过滤。保证这里得到的就是evdev_handler。 因此，在这个input_open_file中，将file->f_ops进行了修改，把file->f_ops 指向了 evdev_handler->ev_fops。这样在 用户态以后调用 read\write等方法时，就会调用到evdev_handler中的方法中。

 

这里有些像是手动实现了 C++中的虚函数和多态。内核中有许多面向对象的思想，还需要多多领悟。

 

下面是evdev_read函数：

 

static ssize_t evdev_read(struct file *file, char __user *buffer,  size_t count, loff_t *ppos){struct evdev_client *client = file->private_data;struct evdev *evdev = client->evdev;struct input_event event;int retval;if (count < input_event_size())return -EINVAL;if (client->head == client->tail && evdev->exist &&    (file->f_flags & O_NONBLOCK))return -EAGAIN;retval = wait_event_interruptible(evdev->wait,client->head != client->tail || !evdev->exist);if (retval)return retval;if (!evdev->exist)return -ENODEV;while (retval + input_event_size() <= count &&       evdev_fetch_next_event(client, &event)) {if (input_event_to_user(buffer + retval, &event))return -EFAULT;retval += input_event_size();}return retval;}

 

在这个函数中实现了read时的阻塞。