From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48848 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OMAmb-0004MS-IP for qemu-devel@nongnu.org; Tue, 08 Jun 2010 22:12:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OMAma-0004cI-97 for qemu-devel@nongnu.org; Tue, 08 Jun 2010 22:12:45 -0400 Received: from mail.codesourcery.com ([38.113.113.100]:52629) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OMAma-0004cA-0D for qemu-devel@nongnu.org; Tue, 08 Jun 2010 22:12:44 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support Date: Wed, 9 Jun 2010 03:11:41 +0100 References: <1275954730-8196-1-git-send-email-aliguori@us.ibm.com> <201006081636.12242.paul@codesourcery.com> <4C0E6894.9000901@redhat.com> In-Reply-To: <4C0E6894.9000901@redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201006090311.44188.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Anthony Liguori , Glauber Costa , qemu-devel@nongnu.org > >>> Once you eliminate machine_register_core that knowledge has > >>> > >>> somehow got to come from your device tree description file. Having a > >>> single device tree that can morph into significantly different machines > >>> seems like unnecessary complexity given this is a user-specified file. > >> > >> 99% of qemu users will never touch a device tree. The practical matter > >> is, we're going to have to provide higher level interfaces that allow a > >> user to significantly morph a base device tree into something different. > > > > That's the bit I don't get. Why are we significantly morphing a base > > device tree? Surely it's easier to just use a different base tree. > > Because at some point the base tree will have to be written in C. No. You can start with a completely empty machine. We don't/shouldn't need any machine specific C code. When I submitted the original qdev code I also posted a proof-of-concept patch that built the whole machine based on a config file with no hardcoded knowledge of the machine structure. > Of course you have to decide where to stop allowing customization, but > anyway it will be significantly more complex than a QemuOpts config > file. QemuOpts obviously doesn't have the flexibility to create an > entire device tree. Why not? The current -device option already provides the majority of the functionality required. Most of the missing bits are incomplete qdev conversion. I'm not saying that creating a whole machine via -device options is an elegant solution (hence the interest in things like FDT) but in I see no reason why it shouldn't work. IMO all uses of the no_user flag are bugs resulting from incomplete/incorrect qdev conversions. > Want to let the user add an IDE controller? Fine, you need to provide > him with a way of writing the following logic: > > for(i = 0; i < MAX_IDE_BUS * MAX_IDE_DEVS; i++) { > hd[i] = drive_get(IF_IDE, i / MAX_IDE_DEVS, i % MAX_IDE_DEVS); > } > pci_piix3_ide_init(pci_bus, hd, piix3_devfn + 1); > > What do you do? -device piix3-ide. See also docs/qdev-device-use.txt Paul