但是,对于Linux输入API,例如,/ dev / input / event0,并且所有进程都能够读取输入事件.
我目前的目标：
我想为几个多位置开关编写驱动程序(例如,具有3个或4个可能位置的滑动开关),其中应用程序可以获得任何开关位置变化的通知.理想情况下,我想使用Linux输入API,但似乎Linux输入API不支持多位置开关的概念.所以我正在研究制作一个与Linux输入API具有类似功能的自定义驱动程序.
两个问题：
>从驱动程序设计的角度来看,为什么Linux输入API和Linux串行设备之间的行为存在差异？我认为,对于所有能够打开一个串行端口并且都监听传入字节的多个进程可能是有用的.
>编写Linux字符设备驱动程序的好方法是什么,它就像Linux输入API,因此多个进程可以打开设备并读取所有数据？
解决方法
>事件子系统设计用于通过非常少(或没有)配置选项将来自多个写入器的简单事件单向通知到系统中.
> tty子系统旨在用于潜在大量数据的双向端到端通信,并提供相当灵活(尽管是相当巴洛克式)的配置机制.
从历史上看,tty子系统是与系统通信的主要机制：将“电传打字机”插入串行端口,然后进出.来自不同供应商的不同电传类型使用不同的协议,因此termios界面诞生了.为了使系统在多用户上下文中运行良好,在内核中添加了缓冲(并且可以进行配置). tty子系统的期望模型是中等智能端点之间的点对点链接,它们将就它们之间传递的数据达成一致.
虽然有些情况下“单个写入器,多个读取器”在tty子系统中是有意义的(例如,连接到串行端口的GPS接收器,不断报告其位置),但这不是系统的主要目的.但是您可以轻松地在用户空间中完成这个“多个读者”.
另一方面,事件系统基本上是一种用于鼠标和键盘之类的中断机制.与远程类型不同,输入设备是单向的,对它们产生的数据几乎不提供控制.缓冲数据也没什么意义.没人会对十分钟前鼠标移动的位置感兴趣.
我希望能回答你的第一个问题.
对于你的第二个问题：“这取决于”.你想要完成什么？什么是数据的“长寿”？您还必须问自己,将复杂性放在内核中是否有意义,或者将它放在用户空间中是不是更好.
将数据输出到多个读者并不是特别困难.您可以为每个阅读器创建一个接收缓冲区,并在数据进入时填充每个接收缓冲区.如果数据的速度快于读者可以使用它,那么事情会变得更有趣,但即便如此,这也是解决的问题.看一下网络堆栈的灵感！
如果您的设备很简单并且只是产生事件,那么您可能只想成为输入驱动程序？
如果不了解更多关于你想要完成的事情,你的第二个问题就更难回答.
添加特定目标后更新：
当我做位置开关时,我通常只创建一个字符设备并实现轮询和读取.如果你想要花哨并有很多开关,你可以做mmap但我不会打扰.
用户空间只需打开/ dev / foo并读取当前状态并开始轮询.当您的开关改变状态时,您只需唤醒读者,他们就会再次阅读.所有的读者都会醒来,他们都会读到新的状态,每个人都会很开心.
当您的交换机“已确定”时,请小心只唤醒读卡器.许多位置开关非常嘈杂,它们会在很多位置反弹.
换句话说：我会完全忽略输入系统.正如你猜测的那样,位置开关并不是真正的“输入”.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
