From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60243 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PnZ1e-0000X7-8p for qemu-devel@nongnu.org; Thu, 10 Feb 2011 11:05:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PnZ1c-0004ou-68 for qemu-devel@nongnu.org; Thu, 10 Feb 2011 11:05:46 -0500 Received: from mail-fx0-f45.google.com ([209.85.161.45]:41386) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PnZ1b-0004of-Q8 for qemu-devel@nongnu.org; Thu, 10 Feb 2011 11:05:44 -0500 Received: by fxm12 with SMTP id 12so1665911fxm.4 for ; Thu, 10 Feb 2011 08:05:42 -0800 (PST) Message-ID: <4D540CC5.2@codemonkey.ws> Date: Thu, 10 Feb 2011 17:05:25 +0100 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] KVM call minutes for Feb 8 References: <4D52F20A.7070009@codemonkey.ws> <4D539800.3070802@codemonkey.ws> <20110210090748.GD673@redhat.com> <4D53BD22.1040800@redhat.com> <20110210111354.GA21681@redhat.com> <4D53DF42.4030700@codemonkey.ws> <20110210132730.GB24525@redhat.com> <4D53F06C.9090500@codemonkey.ws> <20110210142044.GD24525@redhat.com> In-Reply-To: <20110210142044.GD24525@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Chris Wright , kvm@vger.kernel.org, Markus Armbruster , qemu-devel@nongnu.org, Blue Swirl , Avi Kivity 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. >