Il 27/08/2013 01:17, Peter Maydell ha scritto: > On 26 August 2013 23:33, Paolo Bonzini <pbonz...@redhat.com> 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
