> And it's not full emulator if it doesn't emulate the > bugs.
It's almost bedtime in Europe. Do you mind if I tell you a bedtime story? Years ago, a (back then) successful company selling high-end Unix-based workstations, having been designing its own systems and core components for years, started designing a new generation of workstations. As part of their design, they created a dedicated memory controller, which turned out to fit their hardware so well that it was reused on four other workstation motherboard designs. That memory controller had, among many registers, an arbitration register, used to configure the relative priority of onboard devices, as well as expansion slots, to acquire the data bus. Proper setting of this register is necessary to allow on-board devices and expansion slots to correctly perform DMA, while still allowing cache writeback to run and whatnot. The proper value for that register had to be decided at runtime. The recommended logic was to rely upon the minimal initialization done by the firmware, and then clear some bits and set some others depending upon what on-board devices would be present on the particular motherboard artwork, and what would be found in the various expansion slots. However, it turned out that, on the first few revisions of the memory controller, reading from this particular register was not reliable at all. Sometimes, one would read the correct value, and sometimes, one would read a completely wrong value, depending upon the recent activity occuring on the data bus. The hardware engineers could not figure out what exactly caused this. Most importantly, they could not figure out a reliable workaround to get the correct value out of this register. So they asked the software guys for help. And the company's homemade SVR4-based Unix grew a complex logic to decide, once and for all, which value to write to the register, without having to rely upon the previous value. And they told the hardware guys that it was ok not to worry about this issue anymore. OpenBSD runs on these systems, but we are not lucky enough to have all the necessary hardware documentation, and, for some of the bits in this register, we simply don't know when to set them, and when not to set them. Instead, the OpenBSD kernel still reads that register, several times, and has an ugly heuristic to decide when the value read is likely to be correct. And then we only flip the bits we know for certain we can tinker with. It's the best we can do. Assuming someone would write an emulator for that particular system: - if the ``unreliable read'' behaviour is not emulated, according to your logic, it's a bug in the emulator, which has to be fixed. - if the behaviour is emulated, how can we know it is correctly emulated, since even the designers of the chip did not spend enough time tracking down the exact conditions leading to the misbehaviour (and which bogus value would be put on the data bus). You may argue that, since the kernel has a workaround for this issue, this is a moot point. But if some developer has a better idea for the kernel heuristic, how can the new code be tested, if not on the real hardware? Miod
