linux - 在 Linux 内核模块的 ioctl 上获取 ENOTTY

Question

我定义了以下 chardev:

.h

#define MAJOR_NUM 245
#define MINOR_NUM 0
#define IOCTL_MY_DEV1 _IOW(MAJOR_NUM, 0, unsigned long)
#define IOCTL_MY_DEV2 _IOW(MAJOR_NUM, 1, unsigned long)
#define IOCTL_MY_DEV3 _IOW(MAJOR_NUM, 2, unsigned long)

模块.c

static long device_ioctl(
                  struct file*   file,
                  unsigned int   ioctl_num,
                  unsigned long  ioctl_param)
{
    ...
}

static int device_open(struct inode* inode, struct file* file)
{
    ...
}

static int device_release(struct inode* inode, struct file* file)
{
    ...
}

struct file_operations Fops = {
    .open=device_open,
    .unlocked_ioctl= device_ioctl,
    .release=device_release
};

static int __init my_dev_init(void)
{
    register_chrdev(MAJOR_NUM, "MY_DEV", &Fops);
    ...
}
module_init(my_dev_init);

我的用户代码

ioctl(fd, IOCTL_MY_DEV1, 1);

总是失败并出现同样的错误:ENOTTY

Inappropriate ioctl for device

我见过类似的问题: 即

Linux kernel module - IOCTL usage returns ENOTTY

Linux Kernel Module/IOCTL: inappropriate ioctl for device

但他们的解决方案对我不起作用

Answer 1

ENOTTY 是在您的设备驱动程序尚未注册要调用的 ioctl 函数时由内核发出的。恐怕你的函数没有注册好，可能是因为你已经在 struct file_operations 结构的 .unlocked_ioctl 字段中注册了它。

如果您在函数的锁定版本中注册它，您可能会得到不同的结果。最可能的原因是 inode 被 ioctl 调用锁定(应该是这样，以避免对同一设备同时进行 read 或 write 操作的竞争条件)

抱歉，我无法访问 linux 源代码树以获取要使用的字段的正确名称，但您肯定能够自己找到它。

注意

我观察到您使用了宏 _IOW，将主编号用作唯一 标识符。这可能不是您想要的。 _IOW 的第一个参数试图确保 ioctl 调用获得唯一标识符。没有通用的方法来获取此类标识符，因为这是您在应用程序代码和内核代码之间创建的接口(interface)契约。所以使用主要号码是不好的做法，原因有二:

• 多个设备(至少在 linux 中)可以共享相同的主编号(linux 内核中的次要分配允许这样做)使得设备的 ioctl 之间可能发生冲突。
• 如果你改变了主号码(你配置了一个已经分配了那个号码的内核)你必须重新编译你所有的用户级软件来应对新的设备 ioctl id(如果你这样做，它们都会改变)

_IOW 是很久以前(从 linux 内核诞生之日起)构建的一个宏，它试图通过允许您为每个驱动程序选择不同的字符(但不是依赖于其他内核参数，出于上述原因)对于具有 ioctl 调用的设备不与另一个设备驱动程序冲突。这种冲突发生的可能性很低，但是当它发生时，您可能会导致机器状态不正确(您已经向错误的设备发出了有效的、有效的 ioctl 调用)

古代 unix(和早期的 linux)内核使用不同的字符来构建这些调用，因此，例如，tty 驱动程序使用 'T' 作为 的参数>_IO* 宏，scsi 磁盘使用 'S' 等

我建议你选择一个随机数(没有出现在 linux 内核列表的其他地方)然后在你所有的设备中使用它(你写的驱动程序可能比内核中的驱动程序少)并选择一个不同的 ioctl id对于每个 ioctl 调用。以这种方式使用已注册的 ioctl 维护本地 ioctl 文件远比尝试猜测一个始终有效的值要好得多。

此外，看一下 _IO* 宏的定义应该很能说明问题 :)