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

[Anthony Liguori <anthony@codemonkey.ws>]

On 11/24/2010 11:33 AM, Gleb Natapov wrote:
> On Wed, Nov 24, 2010 at 10:40:05AM -0600, Anthony Liguori wrote:
>    
>> On 11/24/2010 10:12 AM, Gleb Natapov wrote:
>>      
>>>        
>>>> 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.
>>>>
>>>>          
>>> Why deny this flexibility from those who need it for modelling
>>> different HW? Besides, as I said, PIIX3 is ISA bridge and this
>>> is what class should implement. We have fw_cfg on ISA bus too
>>> which does not exits on real HW and we may want to have other
>>> devices. We should be able to add them without changing PIIX3
>>> class.
>>>        
>> Because this flexibility is a misfeature.  It's something that noone
>> actually uses and I've never seen anyone ask to have.
>>
>> It introduces a PC-centric view of the world where you artificially
>> make a bunch of devices have bus specific logic that they really
>> don't have.
>>
>>      
> Actually other way around. Non PC embedded systems are those that needs
> this flexibility the most.
>
>
>    
>> If you want to go down this route, the right approach to take is to
>> make a separate IsaMc161818a device that has a Mc16818a device with
>> a has-a relation (i.e. composition).
>>      
> There are many devices in qemu that accessed via isa bus on PCI and via
> MMIO in other archs, so the thing you propose here is logical and
> actually implemented this way in qdev.
>    

Except the Mc16818a device is not a qdev device.

>> But I don't see the point.  Just stick the Mc16818a device in the
>> PIIX3 via composition as it exists on normal hardware and call it a
>> day.
>>      
> Shortcuts, shortcuts. I think this is how qemu was written initially.
> "Lets put this here and call it a day!"
>    

Implementing something correctly in the way that hardware does is not a 
short cut.

>> Right, and real HW does composition in the PIIX3 device. So let's
>> not regret making everything an ISA device later.
>>
>>      
> You design by packaging not functionality?
>    

No, if you want the ability to remove devices from the PIIX3, fine, but 
don't call them ISA devices just for the sake of it.

>>>   Garbage collection can be done
>>> while vcpu executes guest code and in proper implementation vcpu thread
>>> should execute device model code for a very brief time and do not sleep
>>> there. All this makes me think that garbage collection shouldn't be a
>>> big issue for kvm userspace.
>>>        
>> But I don't see the point.  If you look at my repository, there's
>>      
> The point is that C++ is ugly language. The short code Avi sent remind
> me perl (aka line noise). It is almost impossible to parse it into
> what code it actually does. Most symbols are there for C++ syntax not
> functionality.
>    

I'm using C++ to understand how to make a correct design model.  The C++ 
part is only 10% of what I care about.

I agree that Avi's example is not a strong justification for C++ and I 
also agree that it's uglier than the same implementation in C.

>> very few memory allocations.  This is largely due to the fact that I
>> don't overly abstract busses and rely on simple composition where
>> appropriate.
>>      
> I am not sure you can write useful program with few memory allocations.
>    

Ultimately, you're allocating the same amount of memory, but in fewer 
steps (because of static composition).

Regards,

Anthony Liguori

>> Plus, with tr1::smart_pointers, you can be leak free without every
>> worrying about explicit freeing.  There are, of course,
>> possibilities of having circular references but it's not too hard to
>> avoid that in practice.
>>
>>      
> --
> 			Gleb.
>