随笔分类 - liunx设备驱动程序
个人学习使用，所有收集仅供参考。
摘要：为了使用它们, 尽管你不会需要知道内核定时器如何实现, 这个实现是有趣的, 并且值得 看一下它们的内部. 定时器的实现被设计来符合下列要求和假设: 定时器管理必须尽可能简化. 设计应当随着激活的定时器数目上升而很好地适应. 大部分定时器在几秒或最多几分钟内到时, 而带有长延时的定时器是相当少见. 一
阅读全文
摘要：无论何时你需要调度一个动作以后发生, 而不阻塞当前进程直到到时, 内核定时器是给你 的工具. 这些定时器用来调度一个函数在将来一个特定的时间执行, 基于时钟嘀哒, 并且 可用作各类任务; 例如, 当硬件无法发出中断时, 查询一个设备通过在定期的间隔内检查 它的状态. 其他的内核定时器的典型应用是关闭
阅读全文
摘要：当一个设备驱动需要处理它的硬件的反应时间, 涉及到的延时常常是最多几个毫秒. 在这 个情况下, 依靠时钟嘀哒显然不对路. The kernel functions ndelay, udelay, and mdelay serve well for short delays, delaying exe
阅读全文
摘要：到目前为止所展示的次优化的延时循环通过查看 jiffy 计数器而不告诉任何人来工作. 但是最好的实现一个延时的方法, 如你可能猜想的, 常常是请求内核为你做. 有 2 种方 法来建立一个基于 jiffy 的超时, 依赖于是否你的驱动在等待其他的事件. 如果你的驱动使用一个等待队列来等待某些其他事件,
阅读全文
摘要：如我们已见到的, 忙等待强加了一个重负载给系统总体; 我们乐意找出一个更好的技术. 想到的第一个改变是明确地释放 CPU 当我们对其不感兴趣时. 这是通过调用调度函数而 实现地, 在 <linux/sched.h> 中声明: while (time_before(jiffies, j1)) { sc
阅读全文
摘要：设备驱动常常需要延后一段时间执行一个特定片段的代码, 常常允许硬件完成某个任务. 在这一节我们涉及许多不同的技术来获得延后. 每种情况的环境决定了使用哪种技术最好; 我们全都仔细检查它们, 并且指出每一个的长处和缺点. 一件要考虑的重要的事情是你需要的延时如何与时钟嘀哒比较, 考虑到 HZ 的跨各种
阅读全文
摘要：内核代码能一直获取一个当前时间的表示, 通过查看 jifies 的值. 常常地, 这个值只代 表从最后一次启动以来的时间, 这个事实对驱动来说无关, 因为它的生命周期受限于系统 的 uptime. 如所示, 驱动可以使用 jiffies 的当前值来计算事件之间的时间间隔(例如, 在输入驱动中从单击中
阅读全文
摘要：如果你需要测量非常短时间间隔, 或者你需要非常高精度, 你可以借助平台依赖的资源, 一个要精度不要移植性的选择. 在现代处理器中, 对于经验性能数字的迫切需求被大部分 CPU 设计中内在的指令定时不 确定性所阻碍, 这是由于缓存内存, 指令调度, 以及分支预测引起. 作为回应, CPU 制造 商引入
阅读全文
摘要：这个计数器和来读取它的实用函数位于 <linux/jiffies.h>, 尽管你会常常只是包含 <linux/sched.h>, 它会自动地将 jiffies.h 拉进来. 不用说, jiffies 和 jiffies_64 必须当作只读的. 无论何时你的代码需要记住当前的 jiffies 值, 可
阅读全文
摘要：管理存取控制的另一个技术是创建设备的不同的私有拷贝, 根据打开它的进程. 明显地, 这只当设备没有绑定到一个硬件实体时有可能; scull 是一个这样的"软件"设备 的例子. /dev/tty 的内部使用类似的技术来给它的进程一个不同的 /dev 入口点呈现的 视图. 当设备的拷贝被软件驱动创建,
阅读全文
摘要：当设备不可存取, 返回一个错误常常是最合理的方法, 但是有些情况用户可能更愿意等待 设备. 例如, 如果一个数据通讯通道既用于规律地预期地传送报告(使用 crontab), 也用于根据 用户的需要偶尔地使用, 对于被安排的操作最好是稍微延迟, 而不是只是因为通道当前忙 而失败. 当设备不可存取, 返
阅读全文
摘要：单打开设备之外的下一步是使一个用户在多个进程中打开一个设备, 但是一次只允许一个 用户打开设备. 这个解决方案使得容易测试设备, 因为用户一次可从几个进程读写, 但是 假定这个用户负责维护在多次存取中的数据完整性. 这通过在 open 方法中添加检查来实 现; 这样的检查在通常的许可检查后进行, 并
阅读全文
摘要：llseek 方法实现了 lseek 和 llseek 系统调用. 我们已经说了如果 llseek 方法从设备 的操作中缺失, 内核中的缺省的实现进行移位通过修改 filp->f_pos, 这是文件中的当前 读写位置. 请注意对于 lseek 系统调用要正确工作, 读和写方法必须配合, 通过使用和
阅读全文
摘要：提供存取控制的强力方式是只允许一个设备一次被一个进程打开(单次打开). 这个技术最 好是避免因为它限制了用户的灵活性. 一个用户可能想运行不同的进程在一个设备上, 一 个读状态信息而另一个写数据. 在某些情况下, 用户通过一个外壳脚本运行几个简单的程 序可做很多事情, 只要它们可并发存取设备. 换句
阅读全文
摘要：poll 和 select 系统调用的真正实现是相当地简单, 对那些感兴趣于它如何工作的人; epoll 更加复杂一点但是建立在同样的机制上. 无论何时用户应用程序调用 poll, select, 或者 epoll_ctl,[24]24 内核调用这个系统调用所引用的所有文件的 poll 方法, 传递
阅读全文
摘要：使用非阻塞 I/O 的应用程序常常使用 poll, select, 和 epoll 系统调用. poll, select 和 epoll 本质上有相同的功能: 每个允许一个进程来决定它是否可读或者写一个 或多个文件而不阻塞. 这些调用也可阻塞进程直到任何一个给定集合的文件描述符可用来 读或写. 因此
阅读全文
摘要：我们已经见到了 scullpipe 驱动如何实现阻塞 I/O. 如果你想试一试, 这个驱动的源码 可在剩下的本书例子中找到. 阻塞 I/O 的动作可通过打开 2 个窗口见到. 第一个可运行 一个命令诸如 cat /dev/scullpipe. 如果你接着, 在另一个窗口拷贝文件到 /dev/scul
阅读全文
摘要：我们已经见到当一个进程调用 wake_up 在等待队列上, 所有的在这个队列上等待的进程 被置为可运行的. 在许多情况下, 这是正确的做法. 但是, 在别的情况下, 可能提前知道 只有一个被唤醒的进程将成功获得需要的资源, 并且其余的将简单地再次睡眠. 每个这样 的进程, 但是, 必须获得处理器,
阅读全文
摘要：我们已展现的唤醒进程的样子比内核中真正发生的要简单. 当进程被唤醒时产生的真正动 作是被位于等待队列入口项的一个函数控制的. 缺省的唤醒函数[22]22设置进程为可运行的 状态, 并且可能地进行一个上下文切换到有更高优先级进程. 设备驱动应当从不需要提供 一个不同的唤醒函数; 如果你例外, 关于如何
阅读全文
摘要：在 Linux 内核的之前的版本, 正式的睡眠要求程序员手动处理所有上面的步骤. 它是一 个繁琐的过程, 包含相当多的易出错的样板式的代码. 程序员如果愿意还是可能用那种方 式手动睡眠; <linux/sched.h> 包含了所有需要的定义, 以及围绕例子的内核源码. 但是, 有一个更容易的方式.
阅读全文