From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] What to do about non-qdevified devices? Date: Wed, 30 Jan 2013 08:37:03 -0600 Message-ID: <87sj5i68kw.fsf@codemonkey.ws> References: <871ud4gfoa.fsf@elfo.elfo> <510836DD.3010707@suse.de> <87sj5j7jo8.fsf@codemonkey.ws> <87pq0n887o.fsf_-_@blackfin.pond.sub.org> <874nhy3l2q.fsf@blackfin.pond.sub.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: KVM devel mailing list , quintela@redhat.com, Alexander Graf , qemu-devel qemu-devel , Andreas =?utf-8?Q?F=C3=A4rber?= To: Markus Armbruster , Peter Maydell Return-path: Received: from e35.co.us.ibm.com ([32.97.110.153]:38824 "EHLO e35.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752618Ab3A3OhX (ORCPT ); Wed, 30 Jan 2013 09:37:23 -0500 Received: from /spool/local by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 30 Jan 2013 07:37:22 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id EB9E23E40040 for ; Wed, 30 Jan 2013 07:37:09 -0700 (MST) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r0UEbAgN357454 for ; Wed, 30 Jan 2013 07:37:11 -0700 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r0UEdS4p011029 for ; Wed, 30 Jan 2013 07:39:29 -0700 In-Reply-To: <874nhy3l2q.fsf@blackfin.pond.sub.org> Sender: kvm-owner@vger.kernel.org List-ID: Markus Armbruster writes: > Peter Maydell writes: > >> On 30 January 2013 07:02, Markus Armbruster wrote: >>> Anthony Liguori writes: >>> >>> [...] >>>> The problems I ran into were (1) this is a lot of work (2) it basically >>>> requires that all bus children have been qdev/QOM-ified. Even with >>>> something like the ISA bus which is where I started, quite a few devices >>>> were not qdevified still. >>> >>> So what's the plan to complete the qdevification job? Lay really low >>> and quietly hope the problem goes away? We've tried that for about >>> three years, doesn't seem to work. >> >> Do we have a list of not-yet-qdevified devices? Maybe we need to >> start saying "fix X Y and Z or platform P is dropped from the next >> release". (This would of course be easier if we had a way to let users >> know that platform P was in danger...) > > I think that's a good idea. Only problem is identifying pre-qdev > devices in the code requires code inspection (grep won't do, I'm > afraid). > > If we agree on a "qdevify or else" plan, I'd be prepared to help with > the digging up of devices. That's a nice thought, but we're not going to rip out dma.c and break every PC target. But I will help put together a list of devices that need converting. I have patches actually for most of the PC devices. Regards, Anthony Liguori