From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MiW7T-0001Xl-M1 for qemu-devel@nongnu.org; Tue, 01 Sep 2009 12:22:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MiW7P-0001Wi-SJ for qemu-devel@nongnu.org; Tue, 01 Sep 2009 12:22:07 -0400 Received: from [199.232.76.173] (port=39034 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MiW7P-0001WY-L6 for qemu-devel@nongnu.org; Tue, 01 Sep 2009 12:22:03 -0400 Received: from mail-ew0-f223.google.com ([209.85.219.223]:37197) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MiW7P-00009r-5l for qemu-devel@nongnu.org; Tue, 01 Sep 2009 12:22:03 -0400 Received: by ewy23 with SMTP id 23so109446ewy.8 for ; Tue, 01 Sep 2009 09:22:02 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4A9CD334.6000407@redhat.com> References: <4A9B85E5.8040902@redhat.com> <4A9CD334.6000407@redhat.com> From: Blue Swirl Date: Tue, 1 Sep 2009 19:21:42 +0300 Message-ID: Subject: Re: [Qemu-devel] [PATCH, RFC 0/5] Improve device info handling Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel On Tue, Sep 1, 2009 at 10:54 AM, Gerd Hoffmann wrote: > On 08/31/09 17:23, Blue Swirl wrote: >> >> On Mon, Aug 31, 2009 at 11:12 AM, Gerd Hoffmann =C2= =A0wrote: >>> >>> =C2=A0Hi, >>> >>>> 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. =C2=A0We can stick functi= on >>> 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. =C2=A0I'll send out a patch series shortly to make more cl= ear 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 abo= ve >>> 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 t= his > fits nicely into qdev. =C2=A0Not sure how to handle that best for pc ... > > drives are host side state, they don't go into qdev. My idea was that boards (like pc) should be in the long run represented by a qdev. The higher level metamachine would instantiate the "pc" qdev and plug in drives, memory, reset, power button, PCI devices etc. Something like: DeviceState *dev; BoardDevice *s; dev =3D qdev_create(NULL, "pc"); qdev_init(dev); s =3D board_from_qdev(dev); board_add_cpus(s, smp_cpus); board_add_memory(s, RAM_size); board_add_network(s, nd_tables[0]); board_add_block(s, drives_table[0]); board_add_serial(s, serial_hds[0]); board_add_display(s, ds); // DisplayState * But shouldn't the drives, network and char devices be qdevs too, wouldn't it help the metamachine (or "pc" device)?