主设备号和file_operations结构关系； ioctl和unlocked_ioctl， ioctl简单测试例子

最新推荐文章于 2024-01-01 16:24:31 发布

zjc0888

最新推荐文章于 2024-01-01 16:24:31 发布

阅读量9.4k

点赞数

CC 4.0 BY-SA版权

分类专栏： Android 驱动文章标签： file 测试 reference struct 硬件驱动 cmd

本文链接：https://blog.csdn.net/zjc0888/article/details/6890510

Android 驱动专栏收录该内容

22 篇文章

订阅专栏

本文深入探讨了Linux内核中ioctl与unlocked_ioctl的使用场景与区别，解释了为何在某些情况下需要使用unlocked_ioctl替代ioctl，并提供了在应用程序中测试这些函数的方法。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

open一个字符设备的过程是从
VFS层open系统调用 ===> def_chr_fops-->open ===> cdev->fops->open ===> device specific operation

如果是同一类设备，比如系统中有多个framebuffer，那么就把共有的操作放在cdev->fops->open ，这时向系统注册的仅仅是这一个驱动程序；
将这类主设备号相同的一类设备(如/dev/fb0 /dev/fb1等)放在一个数组中，然后在cdev->fops->open 根据次设备号作为Index来调用体现不同设备差异的那些操作，即 device specific operation ，这就是为什么framebuffer/block 等硬件驱动中实现的都不是file_operations这种操作，而是跟具体设备相关的那些操作。
这就是所谓的一类设备都应一种驱动。

可以认为大多数简单的设备，仅仅需要实现到cdev->fops->open 这个位置，等他们变得复杂，能够提炼出共性的时候就需要实现到[红色device specific operation 这个位置。

对于ioctl操作,优先执行f_op->unlocked_ioctl,如果没有unlocked_ioctl,那么执行f_op->ioctl

在学习ＡＲＭ开发中.ioctl在内2.6.32中。file_operatioins中还有ioctl.自己升级到2.6.36时，使用vim 查错源代码时，发现没有ioctl只有unlocked_ioctl与compat_ioctl函数了。

自己改写这个unlocked_ioctl函数，但是，不知如何用应用程序测试，
当在内核使用ioctl函数时，我在应用程序中使用ioctl(fd,"on"

来测试是否调用了ioctl函数。
可是改成unlocked_ioctl函数时，使用unlocked_ioctl()函数时，提示没有这个函数，请问怎么办？
long  test_ioctl(struct file *filp,unsigned int cmd,unsigned long value){
      struct newdev *p = filp->private_data;
      printk("ioctl %X \n",p);
      switch(cmd){
            case 0:
                     p->on();break;
            case 1:
                     p->off();break;
            default:
                     printk("Unknow cmd\n"

;
                     return -EINVAL;
      }
      return 0;
}

struct file_operations fops = {
      .open = test_open,
      .unlocked_ioctl = test_ioctl,
};

void test_on(void){
      printk("test_on test\n"

;
}

void test_off(void){
printk("test_off test \n"

;
}

void initial_device(struct newdev *d){
      d->on = test_on;
      d->off = test_off;
}

应用程序如下:

int main(int argc,char *argv[]){

      int fd;
      char buf[10];
      printf("1\n"

;
      printf("argc[%d]\n",argc);
      if (argc != 2){
            printf("Usage %s string \n",argv[0]);
            return -1;
      }
      printf("2\n"

;

fd = open("/dev/test",O_RDWR);
printf("3\n"

;

if (fd < 0 ){
printf("fd open errror\n"

;
            return -1;

      }
      printf("4\n"

;
      if (!strncasecmp(argv[1],"on",2))
            unlocked_ioctl(fd,0);
      if (!strncasecmp(argv[1],"off",3))
            unlocked_ioctl(fd,1);

      return 0;
}

root@xu-laptop:/usr/src/linux-2.6.36/drivers/new/10th# gcc -o app app.c
/tmp/cc4PWyCc.o: In function `main':
app.c

.text+0xf1): undefined reference to `unlocked_ioctl'
app.c

.text+0x12a): undefined reference to `unlocked_ioctl'
collect2: ld returned 1 exit status

root@xu-laptop:/usr/src/linux-2.6.36/drivers/new/10th# 为了把BKL从内核中慢慢去掉，加入了unlocked_ioctl，但是有很多地方都用到ioctl,所以一直保留着，直到b19dd42f的时候，最后移除了所有对ioctl的使用，才把ioctl从file_operations里面去掉。

所以你在内核里用unlocked_ioctl是没有问题的。

但是你应用程序里面不能用unlocked_ioctl，因为系统调用ioctl是没有改变的，还是原来的系统调用接口，只是系统调用的实现中，vfs_ioctl()变成了unlocked_ioctl，在应用层你根本不用关注内核中的这些实现上的改变，你只需要按照系统调用的用法用就可以了。

所以，在内核module里，你应该用.unlocked_ioctl = test_ioctl;

而在应用层测试的时候，应用的系统调用仍然是ioctl()。

也就时VFS层这个中间虚拟文件层调用我写的unlocked_ioctl，而应用层还是通过ioctl调用VFS里面的函数，我要做的工作由VFS完成了。