On Thu, Feb 10, 2011 at 6:05 PM, Anthony Liguori <anthony@xxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
