Cra*_*een 8 linux linux-device-driver
我注意到对于串行设备,例如/dev/ttyUSB0,多个进程可以打开设备,但只有一个进程获取字节(以先读取它们为准).
但是,对于Linux输入API,例如/dev/input/event0,多个进程可以打开设备,并且所有进程都能够读取输入事件.
我目前的目标:
我想为几个多位置开关编写驱动程序(例如,具有3个或4个可能位置的滑动开关),应用程序可以获得任何开关位置变化的通知.理想情况下,我想使用Linux输入API,但似乎Linux输入API不支持多位置开关的概念.所以我正在研究制作一个与Linux输入API具有类似功能的自定义驱动程序.
两个问题:
小智 9
区别在于部分历史,部分原因是期望模型不同.
该event子系统设计用于通过非常少(或没有)配置选项将来自多个写入器的简单事件单向通知到系统中.
该tty子系统旨在用于潜在大量数据的双向端到端通信,并提供相当灵活(尽管是相当巴洛克式)的配置机制.
从历史上看,tty子系统是与系统通信的主要机制:将"电传打字机"插入串口,然后进出.来自不同供应商的不同电传类型使用不同的协议,因此termios界面诞生了.为了使系统在多用户上下文中运行良好,在内核中添加了缓冲(并且可以进行配置).tty子系统的期望模型是中等智能端点之间的点对点链接,它们将就它们之间传递的数据达成一致.
虽然有些情况下"单个写入器,多个读取器"在tty子系统中是有意义的(例如,连接到串行端口的GPS接收器,不断报告其位置),但这不是系统的主要目的.但是您可以轻松地在用户空间中完成这个"多个读者".
event另一方面,该系统基本上是一种用于鼠标和键盘之类的中断机制.与远程类型不同,输入设备是单向的,对它们产生的数据几乎不提供控制.缓冲数据也没什么意义.没有人会对十分钟前鼠标移动的位置感兴趣.
我希望能回答你的第一个问题.
对于你的第二个问题:"这取决于".你想要完成什么？什么是数据的"长寿"？您还必须问自己,将复杂性放在内核中是否有意义,或者将它放在用户空间中是否更好.
将数据输出到多个读者并不是特别困难.您可以为每个阅读器创建一个接收缓冲区,并在数据进入时填充每个接收缓冲区.如果数据的速度快于读者可以使用它,那么事情会变得更有趣,但即便如此,这也是解决的问题.看一下网络堆栈的灵感!
如果您的设备很简单并且只是产生事件,那么您可能只想成为输入驱动程序？
如果不了解更多关于你想要完成的事情,你的第二个问题就更难回答.
添加特定目标后更新:
当我做位置开关时,我通常只是创建一个字符设备并实现poll和read.如果你想要花哨并有很多开关,你可以做mmap但我不会打扰.
用户空间只需打开/dev/foo并读取当前状态并开始轮询.当您的开关改变状态时,您只需唤醒读者,他们就会再次阅读.所有的读者都会醒来,他们都会读到新的状态,每个人都会很开心.
当您的交换机"已确定"时,请小心只唤醒读卡器.许多位置开关非常嘈杂,它们会在很多位置反弹.
换句话说:我会完全忽略输入系统.正如你猜测的那样,位置开关并不是真正的"输入".
字符设备如何处理这些类型的语义完全取决于驱动程序来定义和实现。
例如，当然可以实现串行设备的驱动程序，该驱动程序将所有读取数据传递到打开字符驱动程序的每个进程。还可以实现一种输入设备驱动程序，将事件仅传递给一个进程，无论哪个进程排队接收最新事件。这只是编写适当的实现代码的问题。
不同之处在于，这一切都归结为一个简单的问题：“什么有意义”。对于串行设备，我们认为通过单个进程处理任何读取数据更有意义。对于输入设备，我们决定将所有输入事件传递到打开输入设备的每个进程更有意义。例如，可以合理地预期，一个进程可能只关心特定的输入事件，例如按下指针按钮#3，而另一个进程想要处理所有指针运动事件。因此，在这种情况下，将所有输入事件分发给所有相关方可能更有意义。
为了简单起见，我忽略了一些附带问题，例如在将串行数据传送到所有读取进程的情况下，当其中一个进程停止从设备读取时会发生什么。在决定如何实现特定设备的语义时，这也是需要考虑的因素。
| 归档时间： |
|
| 查看次数： |
4601 次 |
| 最近记录： |