【010 设备驱动】ioctl和unlock_ioctl有什么区别？

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

Kashine

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

阅读量966

点赞数 1

分类专栏： linux驱动文章标签：驱动开发

本文链接：https://blog.csdn.net/qq_41709234/article/details/131186078

版权

linux驱动专栏收录该内容

55 篇文章 24 订阅

订阅专栏

文章讨论了Linux驱动程序中的ioctl功能，以及它如何被unlocked_ioctl所取代。unlocked_ioctl改进了锁机制，避免使用大内核锁，提高多处理器系统的性能。大内核锁在早期内核中用于保证SMP系统的安全，但其粗粒度锁限制了并发性，现在正逐渐被更精细的锁策略替代。

摘要由CSDN通过智能技术生成

一、ioctl 作用

大部分驱动除了需要具备读写设备的能力外，还需要具备对硬件控制的能力。例如，要求设备报告错误信息，改变波特率，这些操作常常通过ioctl方法来实现。

二、ioctl和unlock_ioctl有什么区别？

kernel 2.6.36 中已经完全删除了struct file_operations 中的ioctl 函数指针，取而代之的是unlocked_ioctl 。

ioctl是老的内核版本中的驱动API，unlock_ioctl是当下常用的驱动API。

unlocked_ioctl 实际上取代了用了很久的ioctl，主要的改进就是不再需要上大内核锁（BKL） （调用之前不再先调用lock_kernel()然后再unlock_kernel()）。

总的来说kernel 开发者正在试图朝移除大内核锁的方向努力，ioctl的移除就是被革命了。相信以后越来越多的内核函数会摆脱大内核锁的依赖，并且大内核锁最终会被移除。

由于失去了大内核锁的保护，所以必须在unlocked_ioctl方法中自行实现锁机制，以保证不会在操作设备的时候（特别在SMP系统中）产生竞态。（也就实现了用小锁替换大锁）

三、大内核锁

早期linux版本对对称多处理(SMP)器的支持非常有限，为了保证可靠性，对处理器之间的互斥采取了‘宁可错杀三千，不可放过一个’的方式：在内核入口处安装一把‘巨大’的锁，一旦一个处理器进入内核态就立刻上锁，其它将要进入内核态的进程只能在门口等待，以此保证每次只有一个进程处于内核态运行。这把锁就是大内核锁。

有了大内核锁保护的系统当然可以安全地运行在多处理器上：由于同时只有一个处理器在运行内核代码，内核的执行本质上和单处理器没有什么区别；而多个处理器同时运行于进程的用户态也是安全的，因为每个进程有自己独立的地址空间。

但是这样粗鲁地加锁其缺点也是显而易见的：多处理器对性能的提示只能体现在用户态的并行处理上，而在内核态下还是单线执行，完全无法发挥多处理器的威力。于是内核开发者就开始想办法逐步缩小这把锁保护的范围。

实际上内核大部分代码是多处理器安全的，只有少数全局资源需要需要在做互斥加以保护，所以没必要限制同时运行于内核态处理器的个数。所有处理器都可随时进入内核态运行，只要把这些需要保护的资源一一挑出来，限制同时访问这些资源的处理器个数就可以了。

大内核锁本质上也是自旋锁，但是它又不同于自旋锁，自旋锁是不可以递归获得锁的，因为那样会导致死锁。但大内核锁可以递归获得锁。大内核锁用于保护整个内核，而自旋锁用于保护非常特定的某一共享资源。

缺点：粒度问题，大内核锁是一种全局锁，即它会锁定整个内核，而不是针对特定的内核数据结构。因此，在某些情况下，它可能会导致锁定过于粗粒度，从而限制并发性。