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

[Blue Swirl]

On Thu, Feb 10, 2011 at 6:05 PM, Anthony Liguori <address@hidden> wrote:
> 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);

I don't see how that would help at all. Throwing qdev away and just
calling various functions directly, with all states exposed would be
like QEMU 0.9.0.

> 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.

There's also qemu_irq for arbitrary signals.

>  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.

And how should this be fixed? The API change would not help.

> 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.

QEMU is developed in C, not C++.

> And it's all unrelated to VMState.

Right, but this has also the good side that not all device state is
automatically exported. If other devices would be allowed to muck with
a devices internal state freely, bad things could happen.

Device reset could also use standard register definitions, shared with 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.

Maybe qemu_irq should be renamed to QEMUSignal (and I don't like
typedeffing pointers), otherwise it looks quite sane to me.

Could you point to examples of SystemBus overuse?

> 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.

We have 'info qtree' which can't be implemented easily without a
generic device class. Avi (or who was it) sent patches to expose even
more device state.

With the patches I'm going to apply, if Redhat wants to disable
building various devices, it can be done without #ifdeffery. This is
not possible without a generic factory interface.