inotify 事件后无法打开 /dev/input/js 文件描述符

Posted 2023-03-15

【中文标题】inotify 事件后无法打开 /dev/input/js 文件描述符

【英文标题】：Can't open /dev/input/js file descriptor after inotify event

【发布时间】：2014-08-19 10:27:36

【问题描述】：

我正在为一个游戏库创建一个 Linux 模块，让您可以热插拔多个游戏杆，它使用 inotify 来观看 /dev/input。

我正在用 3 个操纵杆对其进行测试：

首先我连接了 2 个操纵杆。​​li> 然后我启动应用程序，操纵杆工作，我没有收到错误。 之后我连接第三个操纵杆，perror 给出：/dev/input/js1: Permission denied。 当我检查 ls -l /proc/<pid-of-process>/fd 时，它会列出 /dev/input/js0 和 /dev/input/js2。

当我以 root 身份运行时，所有的操纵杆都可以正常工作。

这是它的初始化方式：

static void createGamepad(char *locName)
    char dirName[30];
    int fd;

    snprintf(dirName, 30, "/dev/input/%s", locName);

    fd = open(dirName, O_RDONLY | O_NONBLOCK, 0);
    if(fd < 0)
        perror(dirName);
    


struct dirent *dir;
DIR *d;
int i, notifyfd, watch;

// Attach notifications to check if a device connects/disconnects
notifyfd = inotify_init();

watch = inotify_add_watch(notifyfd, "/dev/input", IN_CREATE | IN_DELETE);

d = opendir("/dev/input");

i = 0;
while((dir = readdir(d)) != NULL)
    if(*dir->d_name == 'j' && *(dir->d_name + 1) == 's')
        createGamepad(dir->d_name, i);
        i++;
    


closedir(d);

之后 inotify 在 while(1) 循环中像这样处理它：

static bool canReadINotify()
    fd_set set;
    struct timeval timeout;

    FD_ZERO(&set);
    FD_SET(notifyfd, &set);
    timeout.tv_sec = 0;
    timeout.tv_usec = 0;

    return select(notifyfd + 1, &set, NULL, NULL, &timeout) > 0 && 
        FD_ISSET(notifyfd, &set);
 

// Inside the event loop
struct inotify_event ne;

while(canReadINotify())
    if(read(notifyfd, &ne, sizeof(struct inotify_event) + 16) >= 0)
        if(*ne.name != 'j' || *(ne.name + 1) != 's')
            continue;
        

        if(ne.mask & IN_CREATE)
            createGamepad(ne.name);
        
    

是否可以使用 inotify 或者我应该使用 udev？如果可能的话，我该如何解决这个问题？

【问题讨论】：

/dev/input/js1 的文件权限是什么？是否允许您的用户从中读取？

@nos crw-rw-r--+ 1 root root，和js0和js2权限一样。

【参考方案1】：

这很可能是一种竞争条件。您会看到，在创建设备节点时您会收到 inotify 事件（由 udev 使用 mknod() 调用），但访问权限是由 udev 使用单独的 chown() 调用设置的，只是稍晚一点。

见systemd src/udev/udev-node.c, node_permissions_apply()。在这种特殊情况下，/dev/input/jsX 不是符号链接，而是实际的设备节点；至少在 systemd 中，设备节点访问模式会在实际节点创建之后的某个时间设置。

一个可靠的解决方案是修改您的createGamepad() 函数，这样您就不会在fd == -1 && errno == EACCES 完全失败，而是在片刻后重试；至少几次，最多说一两秒钟。

不过，ninjalj 提出了一个更好的建议：同时使用访问权限更改作为触发器来检查设备节点。通过在inotify_add_watch() 函数中使用IN_CREATE | IN_DELETE | IN_ATTRIBUTE，这很容易实现！

（您还需要忽略createGamepad() 中的open()==-1, errno==EACCES 错误，因为它们很可能是由这种竞争条件引起的，并且以下IN_ATTRIBUTE inotify 事件将产生对同一设备的访问权。）

在 ninjalj 发表评论之前，我个人会使用一组输入设备，另一个用于“可能”的输入设备，这些设备可以/需要在短暂超时后重试以确定它们是否可用，但我认为他的建议要好得多。

需要/想要一个例子？

【讨论】：

当他们的权限改变时，操纵杆设备节点不会收到 IN_ATTRIB inotify 事件吗？如果是这样，OP 也可以监视该事件，无需重试。

@ninjalj：我检查过，确实你得到了IN_ATTRIB inotify 事件。我认为应该可以正常工作；很好的建议！ motash，你只需要使用IN_CREATE | IN_DELETE | IN_ATTRIB而不是IN_CREATE | IN_DELETE，并忽略errno==EACCES错误，尝试ninjalj的建议解决方案。

谢谢你们，IN_ATTRIB 活动就像一个魅力！如果你能把它放在一个答案中，我可以接受它并奖励积分。

@ninjalj：这是你的主意；随时提交答案以获得积分！

@NominalAnimal：您诊断出了问题。我只是建议对您的解决方案进行可能的改进。