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