前向兼容硬件检测
作为一个软件迷，我目前正在与一些硬件技术人员就硬件检测机制进行斗争。
我觉得应该有可能建立一个“面向未来”的检测/发现机制，今天构建的检测软件将能够识别未来开发的所有硬件版本的一组有限属性。
反对的论点：当前的（dsp）芯片可能在不久的将来就会过时；因此，我们不能保证未来的主板将与当前的发现协议兼容。
对于 USB、PnP 等，这是如何完成的？还有其他示例吗？
Being a softie, I'm currently fighting some hardware techies on a hardware detection mechanism.
I feel like it should be possible to build a detection/discovery mechanism that is 'future proof', in a way that the detection software, built today, will be able to recognize a limited set of properties of all hardware versions developed in the future.
The argument against: the current (dsp) chip may become obsolete in the near future; hence, we cannot guarantee that future boards will be compatible with the current discovery protocol.
How is this done for e.g. USB, PnP, and are there other examples?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
正如您所暗示的那样，答案的关键在于协议中。它可能并不总是很漂亮，有时你会将自己锁定在设计中。
然而，PC架构本身就证明了前向检测的可行性。
通常完全可以在今天购买的系统上启动 1996 年编译的 Linux 内核。 Linux 系统可能无法使用该系统中的大部分硬件，但它会发现任何子集仍然相同。
然而，它需要一个非常明智的硬件检测方案或生存意愿与拼凑（参见PC上的A20行设置，最初使用键盘控制器）或同时两者。 （就像当今几乎所有 PC 内部都具有旧的 ISA 总线以支持 PS/2 键盘等功能一样，而且还具有 PCI 协议。）
为了工作，我为子板设计了一种 ID ROM 格式。它们具有紧凑的二进制 XML 或类似 Lisp 的结构，其中包含一些必填字段、几个可选字段和一个版本号。任何全新的硬件都可以增加版本号并添加新软件所需的任何数据，同时仍然告诉旧软件旧领域中适当的信息。
这样至少旧软件可以检测到板子ID、用途，然后放弃。这就是 USB 设备的工作原理。所有旧软件都可以枚举新设备，但远不能确定旧软件是否可以以任何有意义的方式驱动新硬件。键盘、鼠标和记忆棒是例外，每个人都坚持旧的“应用程序级别”，可以说是协议。
The key to the answer is in the protocol, just as you are hinting at. It may not always be pretty, and sometimes you are locking yourself into a design.
However, the PC architecture itself is proof of feasibility of forward detection.
It is often entirely possible to boot a Linux kernel compiled in say, 1996 on a system purchased today. The Linux system may not be able to use much of the hardware in that system, but it will find whatever subset is still the same.
It requires however, either a very wise hardware detection scheme or a willingness to live with kludges (see the line A20 setup on PCs, originally using the keyboard controller) or both at the same time. (Like how almost all PCs today both has the old ISA bus internally for things like PS/2 keyboard support, but also have the PCI protocol.)
For work, I designed an ID ROM format for daughter boards. They had a compact, binary XML or Lisp-like structure with a few mandatory fields, several optional, and a version number. Any completely new hardware can increment the version number and add any data necessary for new software, while still telling old software whatever appropriate in the old fields.
So that at the very least, the old software can detect the board ID, purpose, and then give up. This is much how USB devices work. All old software can enumerate new devices, but it is far from certain that the old software can drive the new hardware in any meaningful way. Exceptions are keyboards, mice and memory sticks, where everybody sticks to the old "application level", so to speak, protocols.
有一个可配置的供应商 ID 和设备 ID，以标准方式传输到操作系统。负责它的驱动程序以这种方式识别硬件。因此，如果您在驱动程序中知道设备 ID，那么您就会知道它是否兼容。如果设备 ID 保持不变，那么您应该使用一些可以读取的内存映射寄存器来包含一些额外的信息（推荐！），例如硬件设计版本等。
无论如何，驱动程序必须知道它正在与什么硬件通信并做出相应反应。有一些标准方法来正确检测硬件是一个设计问题。因此，请就存储此信息的一些地址达成一致并坚持下去。还要以将来可以扩展的方式设计它。
There is a configurable Vendor ID and Device ID that is transmitted to the OS in a standard way. The driver responsible for it recognizes the hardware this way. So if you know in the driver the device id then you will know if it is compatible. If the device ID remains the same then you should use some memory mapped registers that can be read out to contain some extra information (which is recommended!) like the hardware design version, etc.
Anyway the driver MUST know what hardware it is talking to and react accordingly. It is a matter of design to have some standard way to detect the hardware correctly. So agree on some addresses where this info is stored and stick to it. Also design it in a way it can be extended in the future.