From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MiOCR-00065o-R9 for qemu-devel@nongnu.org; Tue, 01 Sep 2009 03:54:43 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MiOCN-00065U-Ah for qemu-devel@nongnu.org; Tue, 01 Sep 2009 03:54:43 -0400 Received: from [199.232.76.173] (port=47406 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MiOCN-00065R-71 for qemu-devel@nongnu.org; Tue, 01 Sep 2009 03:54:39 -0400 Received: from mx20.gnu.org ([199.232.41.8]:3378) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MiOCM-00080l-FW for qemu-devel@nongnu.org; Tue, 01 Sep 2009 03:54:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MiOCK-0001E1-S8 for qemu-devel@nongnu.org; Tue, 01 Sep 2009 03:54:37 -0400 Message-ID: <4A9CD334.6000407@redhat.com> Date: Tue, 01 Sep 2009 09:54:28 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH, RFC 0/5] Improve device info handling References: <4A9B85E5.8040902@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel On 08/31/09 17:23, Blue Swirl wrote: > On Mon, Aug 31, 2009 at 11:12 AM, Gerd Hoffmann wrote: >> Hi, >> >>> Add info command registration to the API and make some devices use it. >> >> Jumping in here with a more general comment ... >> >> I think right now we have _way_ to much register_something functions. >> IMHO qdev allows us to kill off most of them. We can stick function >> pointers (also VMstate pointers) into DeviceInfo instead of registering >> callbacks. > > Good idea. I wish reset could be handled also with a structure. reset is easy. I'll send out a patch series shortly to make more clear what I'm talking about. >> Short-term (while we are in the "convert-drivers-to-qdev" phase) that will >> just move the register calls from the driver code to generic qdev code. >> >> Long-term we hopefully can kill the register calls altogether and walk the >> qdev device tree instead. > > So at this stage, the registration function should take a structure > argument but later it would be sucked into qdev? Now: registration moves from drivers to qdev.c Later: no registration needed any more, all info needed is in the qdev device tree. >> Hmm, i8259 isn't converted to qdev yet, so the route outlined above above >> will not work (yet) for this device ... > > There is also no qdev for pc.c. Maybe there should be one qdev for > each board? The higher level could set up common things like system > reset signal, memory, drives etc. Maybe even PCI. IIRC openfirmware has one (or more?) device tree entries for memory, so this fits nicely into qdev. Not sure how to handle that best for pc ... drives are host side state, they don't go into qdev. cheers, Gerd