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

[Gleb Natapov]

On Fri, Feb 11, 2011 at 08:14:16PM +0200, Blue Swirl wrote:
> 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.
Probably. But if this aspect affects the overall re-design of device tree it
is not so minor after all.

> >
> > 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.
> 
That is my sentiment exactly. This is what we had before. What was the
reason we wanted device tree (let alone specific implementation of it
that was committed without much external input)? Why do you no longer want
device tree abstraction? 
 
> > 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.

--
                        Gleb.