到Linux(L)问题

我们从您拥有完善的操作系统这一事实着手,立即为所有事情支付了全部费用。(比尔·盖茨回应有关与L.竞争的问题。)


我对Linux的了解越多,对B.G的厌恶就越少。


好吧,实际上,我从未对他有过如此强烈的感情,我才刚刚开始更好地理解为什么生产Windows的公司能赚钱。而且,更清楚的是,为什么消费者更愿意支付账单(当然,您可以理解,这里有选择权),而不是使用免费(即“免费”)替代方案。但是让我们按顺序开始,并考虑与L交互的两个情节。

最近,L一直在我开发的设备上运行(以您理解的一种或另一种形式),在该设备上执行了专用软件。并且在与外部设备(专用键盘)进行交互的过程中,发现了有趣的OS行为伪像,这导致了题词中提出的想法。

第1集-在纠正USB键盘程序的过程中,引入了“意外,无意”的缺陷,导致设备的字符串描述符失败。对于不十分了解USB的用户,必要的说明(字符串描述符)是设备说明的可选部分,其目的仅在于可视化设备的类型和系统实用程序的制造商。但是,这不是程序员的借口,不应犯此类错误,但一切都会发生。如果连接了错误的设备,运行正常操作系统的主机会如何反应?

我个人认为有3种可能的策略:

  1. 忽略该错误并进一步使用该设备,尤其是因为它没有任何障碍-这是Windows所做的,至少从7开始。
  2. 将设备标记为故障,发出适当的系统消息,然后忽略该设备,这也是完全正常且有意义的反应;
  3. 重复字符串描述符的请求并直到收到请求之前不开始使用此设备本身也是一种可以接受的解决方案,尽管它比以前的设备差一些,因为它占用了处理器和USB总线资源的某些部分(而且它们并不是无限的)。

PNP:应该注意的是,接口标准仅满足需要(在第222页上的图8.31),同时等待输入消息以控制时间并处理超时,这是可能的错误之一-重复请求3次,然后发出有关事务失败的信号。进一步的主机操作由实现决定。好吧,至少我没有在标准中找到这样的信息,尽管这不是最终的。

因此,L的开发人员并没有将自己局限于表面和更深层次的解决方案上,他们提出了一种非常有趣的方法,并且我们将不惧怕这个词,这是愚蠢的非常有创意的方式:

4.将请求重复几次,用尽之后将其标记为有缺陷的设备然后将其关闭。

到目前为止,如果不是一个小细节(“还有其他一切都是细微的差别”),L主机将重复上述请求,但它会通过总线垄断访问(很可能硬件中的超时不会开始或中断不会被处理),这是没有犯罪的。所有其他(!!!)USB设备均处于空闲状态。此过程大约需要十二秒钟,在此期间所有设备都不可用-已经不错。这就是蛋糕上的樱桃-在尝试从错误的键盘上读取字符串描述符的尝试结束之后,数据包通常停止向其发送,在2分钟后,它理解“出了点问题”,并尝试向主机展示通过重新连接再次进行,导致该过程重复。结果是可以理解的-如果您不准备使用打ic模式,则根本无法使用总线。一个不寻常的原始解决方案,但这(原始性)是它唯一的优势。

我的Linux熟人在演示了这种现象之后,首先尝试以“这不是bug,它是这样的功能”的方式来解释它(或者,起初,他们接受了建议,建议使用最新的补丁程序来重建内核,这通常是对L社区中任何信息的普遍回应。关于可能的错误),然后他们说是的,这种行为是不正确的,但是可能在程序集的配置文件中的某个位置有一个标志,重置或设置,您可以禁用此系统行为。如果是这样,那么我可以提供的唯一标志名称是(俄语):“我真的想要to_OS_be_being_being_being_something_failing_string_descriptor_as_hysterichka”,其样式为“直到这只bit子告诉我她的名字,我才不会要求任何人与您交谈”对不起,我的法语。好吧,即使是这种情况,也有这样的标记,默认情况下是否不应该以正常,不变态的模式收集操作系统?由于某些原因,Windows会这样做。当然,您应该查看主机L的源文本(最有可能是特定的USB驱动程序),并确定是否存在这样的标志以及如何实现类似的系统行为,但是由于下面列出的原因,此操作没有完成,因此我们只限于说明事实。

第二个功能(更像是一个错误,因为在第一种情况下,设备是不正确的,我立即强调了这一点)是在修复了设备程序错误并开始进一步工作之后才检测到的。

事实是,在设计的设备上有两个控制器,每个控制器都实现操纵杆和键盘功能,一个控制器处理键盘的左侧,第二个控制器处理右侧。但是前面板上的一个按钮已连接到两个控制器,因为它上面带有“ FIRE”标记,并且一个控制器发生故障的后果将非常令人不快。当您按下该按钮时,两个控制器都显示一个空格字符,一切都很好,直到我们注意到松开A按钮后有时(大约占案例的10%),仍将其视为按下状态,并且应用程序进入连续触发模式。同时,再次按下和放下按钮可使系统返回正常模式。

已经建议可以跳过键盘上间隔很近的事件(在时间上),在这种情况下,有关释放按钮的消息。

此外,已采取各种步骤来确定故障原因,但对它们的描述超出了本文的范围和主题,并且(希望如此)将分别进行描述。但是,找出这种简单(乍看起来)错误的原因的过程本身需要付出如此努力,以至于失去了理解该帖子中描述的第一个bug的原因的任何愿望。
回到题词,我必须说在Windows 7上至少100次单击都未观察到此缺陷,这表明此操作系统在此因素上的稳定性。同样,我没有看到源代码,但是程序的行为说明了一切。

Windows开发人员的资格不太可能大大超过开源社区的资格,显然,问题仅在于测试,当为自己的工作赚钱的人参与其中时,测试无疑会以更大的数量(以及更高的质量)进行(除了道德上的满足)。

我必须承认,至少在描述的情况下,A的行为最好由短语“它起作用”来定义,这对于声称可靠且广泛使用的OS不能被接受,这就是我对B.G.的态度。这一集的结果使情况有所改善,因为他绝对不应该为发生的事情负责(尽管可能会有不同的意见)。

All Articles