From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37749) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VE5b2-0002fa-1B for qemu-devel@nongnu.org; Mon, 26 Aug 2013 18:49:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VE5at-00019B-Ia for qemu-devel@nongnu.org; Mon, 26 Aug 2013 18:49:15 -0400 Received: from mail-ye0-x233.google.com ([2607:f8b0:4002:c04::233]:61233) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VE5at-000197-EP for qemu-devel@nongnu.org; Mon, 26 Aug 2013 18:49:07 -0400 Received: by mail-ye0-f179.google.com with SMTP id l10so1020527yen.38 for ; Mon, 26 Aug 2013 15:49:07 -0700 (PDT) Sender: Richard Henderson Message-ID: <521BDB5E.1040001@twiddle.net> Date: Mon, 26 Aug 2013 15:49:02 -0700 From: Richard Henderson 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: <521BD7D5.6090901@redhat.com> 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: Paolo Bonzini Cc: =?UTF-8?B?w4Frb3MgS292w6Fjcw==?= , qemu-devel@nongnu.org On 08/26/2013 03:33 PM, 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. > > 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). > > 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. All reasonable. Thanks for the rationale. r~