Re: [Qemu-devel] [PATCH 06/47] hw/alpha/Makefile.objs: Build objects depending on CLIPPER

[Paolo Bonzini]

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