Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/10/2011 03:20 PM, Gleb Natapov wrote:
> Jugging by how well all previous conversion went we will end up with one
> more way of creating devices. One legacy, another qdev and your new one.
> And what is the problem with qdev again (not that I am a big qdev fan)?
>    

We've really been arguing about probably the most minor aspect of the 
problem with qdev.

All I'm really saying is that we shouldn't tie device construction to a 
factory interface as we do with qdev.

That simply means that we should be able to do:

RTC *rtc_create(arg1, arg2, arg2);

And that a separate piece of code decides which devices are exposed 
through -device or device_add.  Which devices are exposed is really a 
minor detail.

That said, qdev has a number of significant limitations in my mind.  The 
first is that the only relationship between devices is through the 
BusState interface.  I don't think we should even try to have a generic 
bus model.  When you look at how badly broken PCI hotplug is current in 
qdev, I think this is symptomatic of this.

There's also no way in qdev to really have polymorphism.  Interfaces 
really aren't meaningful in qdev so you have things like PCIDevice where 
some methods are stored in the object instead of the class dispatch 
table and you have overuse of static class members.

And it's all unrelated to VMState.

And this is just the basic mechanisms of qdev.  The actual 
implementation is worse.  The use of qemu_irq as gpio in the base class 
and overuse of SystemBus is really quite insane.

And so far, the use of qdev has been entirely superficial.  Devices 
still don't make use of bus level interfaces to do I/O so we don't have 
any better componentization than we did before qdev.

> The fact that there is no enough interest to convert all devices to it?
>    

I don't think there is any device that has been improved by qdev.  
-device is a nice feature, but it could have been implemented without qdev.

Regards,

Anthony Liguori

> How new way of doing things will solve this?
>
> Just to be clear I do not have problem with not having ability to
> compose x86 without pit or kbd controller. Basic things like RTC, pit,
> pic, ioapic, dma, kbd should be created unconditionally as part of x86
> pc machine. But IMHO you are trying to take things to other extreme.
>
> --
>                         Gleb.
>