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. > 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. > 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). Providing a config system is providing knobs we don't have at the moment. -- PMM
