Re: [PATCH kvm-unit-tests 2/4] Introduce a C++ wrapper for the kvm APIs

[Anthony Liguori <anthony@codemonkey.ws>]

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
>