From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42807 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PoYBu-0007DU-24 for qemu-devel@nongnu.org; Sun, 13 Feb 2011 04:24:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PoYBs-0005mG-OS for qemu-devel@nongnu.org; Sun, 13 Feb 2011 04:24:25 -0500 Received: from mx1.redhat.com ([209.132.183.28]:3315) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PoYBs-0005lR-F5 for qemu-devel@nongnu.org; Sun, 13 Feb 2011 04:24:24 -0500 Date: Sun, 13 Feb 2011 11:24:16 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] KVM call minutes for Feb 8 Message-ID: <20110213092416.GR14984@redhat.com> References: <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> <4D540CC5.2@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Chris Wright , kvm@vger.kernel.org, Markus Armbruster , qemu-devel@nongnu.org, Avi Kivity On Fri, Feb 11, 2011 at 08:14:16PM +0200, Blue Swirl wrote: > On Thu, Feb 10, 2011 at 6:05 PM, Anthony Liguori = wrote: > > On 02/10/2011 03:20 PM, Gleb Natapov wrote: > >> > >> Jugging by how well all previous conversion went we will end up with o= ne > >> more way of creating devices. One legacy, another qdev and your new on= e. > >> 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); >=20 > 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. >=20 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?=20 =20 > > And that a separate piece of code decides which devices are exposed thr= ough > > -device or device_add. =9AWhich devices are exposed is really a minor d= etail. > > > > That said, qdev has a number of significant limitations in my mind. =9A= The > > first is that the only relationship between devices is through the BusS= tate > > interface. >=20 > There's also qemu_irq for arbitrary signals. >=20 > > =9AI don't think we should even try to have a generic bus model. > > =9AWhen you look at how badly broken PCI hotplug is current in qdev, I = think > > this is symptomatic of this. >=20 > And how should this be fixed? The API change would not help. >=20 > > There's also no way in qdev to really have polymorphism. =9AInterfaces = 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 an= d you > > have overuse of static class members. >=20 > QEMU is developed in C, not C++. >=20 > > And it's all unrelated to VMState. >=20 > 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. >=20 > Device reset could also use standard register definitions, shared with VM= State. >=20 > > And this is just the basic mechanisms of qdev. =9AThe actual implementa= tion is > > worse. =9AThe use of qemu_irq as gpio in the base class and overuse of > > SystemBus is really quite insane. >=20 > Maybe qemu_irq should be renamed to QEMUSignal (and I don't like > typedeffing pointers), otherwise it looks quite sane to me. >=20 > Could you point to examples of SystemBus overuse? >=20 > > And so far, the use of qdev has been entirely superficial. =9ADevices s= till > > don't make use of bus level interfaces to do I/O so we don't have any b= etter > > 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. =9A-d= evice > > is a nice feature, but it could have been implemented without qdev. >=20 > 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. >=20 > 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.