From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54818) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VEDGP-0006Kz-Jm for qemu-devel@nongnu.org; Tue, 27 Aug 2013 03:00:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VEDGH-0005gi-RH for qemu-devel@nongnu.org; Tue, 27 Aug 2013 03:00:29 -0400 Received: from mail-we0-f176.google.com ([74.125.82.176]:52443) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VEDGH-0005gV-L4 for qemu-devel@nongnu.org; Tue, 27 Aug 2013 03:00:21 -0400 Received: by mail-we0-f176.google.com with SMTP id q56so3472601wes.7 for ; Mon, 26 Aug 2013 23:59:45 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <521C4E5D.3010103@redhat.com> Date: Tue, 27 Aug 2013 08:59:41 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1377471536-12423-1-git-send-email-akoskovacs@gmx.com> <1377471536-12423-7-git-send-email-akoskovacs@gmx.com> <521B6909.9020708@twiddle.net> <521B8975.9020806@redhat.com> <521B90B8.1020609@twiddle.net> <521BD7D5.6090901@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 06/47] hw/alpha/Makefile.objs: Build objects depending on CLIPPER List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: =?UTF-8?B?w4Frb3MgS292w6Fjcw==?= , QEMU Developers , Richard Henderson Il 27/08/2013 01:17, Peter Maydell ha scritto: > On 26 August 2013 23:33, Paolo Bonzini wrote: >> Il 26/08/2013 19:30, Richard Henderson ha scritto: >>> This isn't the kernel, where non-pagable code size is a concern, so I don't see >>> how full configuration of machine emulations and devices is helpful. I'd be >>> more inclined to go the other way, where all qemu-system-cpu images always >>> build in all devices (compiled once of course). >> >> This is useful for different usecases. One is QEMU that is bundled into >> development platform such as the Android emulator. Making it easier to >> build limited versions of QEMU is one small step towards encouraging >> working in-tree instead of having out-of-tree patches which quickly >> become forks. > > I simply don't believe that this is anything remotely approaching a > major reason why the Android emulator is out of tree, or that merging > this patchset would have any visible effect in moving the Android emulator > into the tree. Anybody from Google is of course welcome to contradict me > on this point. No, it's not anything remotely approaching a major reason. But still, modifying default-configs/ is one of the out-of-tree patches that any external emulator has to include. >> The second is in distros that only want to distribute the subset of >> features that are going to be supported (aka RHEL). This includes both >> devices (all of PCI, ISA, USB) and boards (-M isapc is removed nowadays, >> perhaps one day goldfish or similar will be available too; for ARM and >> PPC we surely would want to compile out almost all the boards). > > Hrm. Yeah, I can see the security argument for wanting a very > stripped down build for the KVM/production use. > >> The third is that in the future some of the devices could be compiled as >> modules, too. This would help the "other" set of distros, those that >> include everything. QEMU now has an insane set of dependencies, and >> having modules for e.g. SPICE or RBD or Gluster would help making them >> optional. > > I thought the plan was to address that by having a module system, > not by having a huge config system. You still build everything all > at once, you just split the binaries/shared objects you ship as a > distro into multiple packages. Sure. But the above stripped-down build might just as well be monolithic, so you need to configure what is a module and what is not. >> Note that the Kconfig project is about giving end users _less_ config >> options. > > From my perspective it seems to be giving users more options, > because at the moment there are none -- you just compile QEMU > and you get everything. Nobody should (IMHO) be editing > default-configs/ (despite the slightly confusing name). At least RHEL is doing so (and RHEL originally motivated the first big Makefile reorganization by Juan around 4 years ago, and the introduction of default-configs). Even though this is a summer of code project, my proposal was driven by an actual need (and curiosity of course). Paolo