On 11/24/2010 06:40 PM, Jes Sorensen wrote:
>>> >> The fact that in physical implementation they sit in the same silicon >> does not mean that logically they belong to the same class. PIIX3 >> is ISA bridge. It doesn't mean it owns devices on the ISA bus it >> provides. The information that you are trying to convey here belongs to >> configuration file. > > Why would we specify a PIIX3 device based on a configuration file? > There is only one PIIX3 device in the world. I don't see a lot of need > to create arbitrary types of devices. 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. What you did above is making the exact same mistake as is done with the current i440fx.c code.
If a real life 440fx has an i8042, then an emulated 440fx should have an emulated i8042. It's not complicated.
>>> So whereas we have this very complicate machine create function that >>> attempts to create and composite all of these devices after the >>> fact, when written in C++, partially due to good design, but >>> partially due to the fact that the languages forces you to think a >>> certain way, you get a tremendous simplification. That is clearly dependent on the eyes of the person who looks at it.
It's independent of language. It should be done in C as well. C++ just makes it easier by reducing the boilerplate.
-- error compiling committee.c: too many arguments to function -- 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
