On 11/24/2010 10:40 AM, Jes Sorensen wrote:
Well the problem here is that the i8042 is in the i440fx.c file, it
shouldn't be there in the first place. The gluing together things in
silicon is really just a way to shorten the wires and make it easier,
they are still separate devices and as long as the i8042 requires ISA
access, and to be treated like an ISA device, we should glue it onto the
virtual ISA bus within QEMU.
Nope. The PC is much, much uglier than everyone seems to realize.
Part of the reason the PIIX3 implements the i8042 (and the i440fx
implements the PIIX3) is because the i8042 is needed to lower the a20
line. IOW, the i8042 has to signal to the memory controller to modify
accesses to memory addresses from the CPU.
It's not just a statement of cost savings. One of the reasons
everything's in the same piece of silicon is because of the horribly
incestuous nature of the PC architecture. It's not a nice tree of
parent busses and children devices. It's an interbreeding group of
devices who's parent's are their siblings and brother's are their uncles.
I think it's a lot of abstraction for very little gain and leads to
bizarreness like treating any platform device as an ISA device.
An RTC is *not* an ISA device. It may sit *behind* an ISA bus because
the SuperIO chip happens to be on the ISA bus. But on modern systems,
the ISA bus has disappeared in favor of the LPC but that doesn't
fundamentally change what the RTC is.
The problem with what you describe is that there are far fewer devices
that actually sit on busses than what QEMU tries to model today.
A PCI device is mapped on a PCI bus as a PCI function etc. If the device
is hard wired to a fixed address, or worse a fixed IO port, then it is
an ISA device.
Wrong. The PCI controller sends all port and memory I/O operations
over the bus. Any PCI device can select to handle any address they want
by simply issuing a DEVSEL. The ability to do switching wasn't
introduced until PCI-X.
The way a PCI-to-ISA bridge works is by waiting for a full bus cycle to
see that no device has issued a DEVSEL, and then issuing a DEVSEL. This
is called subtractive decoding. It then forwards the I/O request over
the ISA bus and roughly the same thing happens on the ISA bus.
That is if you are using code as data. With other design you actually
read I440FX configuration from file and build it from smaller parts.
You see C++ doesn't stop us from arguing what design is correct.
That's fair. I think 90% of what we need is better design. I think a
better language only gives us 10%.
Well the problem is the 10% you are talking about is another 30% loss
because the code is now practically unreadable, plus you open up the can
of worms that people will start using some of the totally broken
features of C++.
Did you look at my code or Avi's code?
Look at my code and then tell me it's practically unreadable.
http://git.qemu.org/qemupp.git/tree/test/test-mc146818a.cpp
Sure you can try hard to make sure they don't sneak in,
but down the line they will, and at that point the codebase is totally
ruined.
Avi's unittest code is a perfect example of code that is unreadable for
a C programmer. Or to quote a smart man 'the code is clear as perl!'.
So you have now lost or at least crippled half your developer base,
making it way harder for them to contribute something useful.
This is a big step in the wrong direction :(
I wouldn't have written the unittest code to use classes or exceptions
at all. I don't think it's a good fit.
Regards,
Anthony Liguori
Jes
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
