Re: [Qemu-devel] [PATCH] build: introduce target CONFIG_ variables and use them for kvm

[Anthony Liguori <anthony@codemonkey.ws>]

On 06/21/2012 07:31 AM, Paolo Bonzini wrote:
> (Sorry for breaking the thread).
>
>> This avoids the problem associated with having multiple target specific files
>> in a single directory with the current build system.
>
> What is exactly the problem?

Peter's got an ARM specific KVM device he wants to stick in hw/kvm.

Right now, kvm/ is all x86 specific and wants CONFIG_KVM && CONFIG_I386.  We 
gets this by doing:

hw/${TARGET}/Makefile.objs  <=  CONFIG_I386

And then within Makefile.objs:

obj-$(CONFIG_KVM) += kvm/

But this applies for the whole directory.  Previously, you did:

obj-$(CONFIG_KVM) += kvm/apic.o kvm/clock.o ...

The way you did it made it possible for hw/arm/Makefile.obj to have a different 
set of objects but also didn't use sub directory makefiles.

So this patch allows us to achieve CONFIG_KVM && CONFIG_I386 by doing:

hw/Makefiles.objs:

obj-$(CONFIG_KVM) += kvm/

hw/kvm/Makefiles.obj:

obj-$(CONFIG_I386) += apic.o clock.o

Which I think is actually more straight forward.  This gives us the logic we 
need and let's use us subdirectory makefiles too.

>
> I saw something about dependencies, I think that should be solved with
> something like
>
> $(foreach var, $(nested-vars), $(eval -include $(patsubst %.o, %.d, $($(var)))))
>
> at the very end of unnest-vars.

Already added that BTW :-)  That's a different thread.

>> We can eventually get rid of the hw/$BASE_ARCH/Makefiles.obj files too
>
> The goal should be to limit hw/$BASE_ARCH/Makefile.objs to hardware
> that is CPU-dependent and to board descriptions.
>
> I _think_ (but I don't have a checkout at hand) that hardware like
> virtio can use obj-$(CONFIG_VIRTIO) while staying in hw/Makefile.objs,
> but it should really be the only case of target-dependent file in hw/.
>   Everything else in hw/$BASE_ARCH should move to target-$BASE_ARCH/hw.
>   The steps should be as follows:

Yup, I'm trying to refactor some of this.

Most of what's in hw/$BASE_ARCH today is really just hardware that doesn't apply 
to any other targets but is not truly target specific.

We could introduce per-device CONFIG variables and update all of the 
default-configs/ but that's a big pain for marginal benefit.  Instead, I think 
what we want in the long term is to have machine-specific CONFIG variables. 
Something like CONFIG_PC or CONFIG_VERSITALE.

But in the very short term, CONFIG_I386 makes a good stepping stone to CONFIG_PC 
and let's use refactor the Makefiles such that we can introduce more granular 
CONFIG_* down the road without changing object locations.

I think that's really the way to think of it.  We start with big guards 
(CONFIG_I386) and over time break them down into smaller guards (CONFIG_PC).

> 1) Identify more groups of hardware that can be moved from
> hw/$BASE_ARCH to libhw. Move them.
>
> 2) At this point, hw/$BASE_ARCH/Makefile.objs should only refer to a)
> boards b) hardware that is CPU dependent c) KVM device models with
> host dependencies. Move the sources to hw/$BASE_ARCH, possibly
> hw/$BASE_ARCH/kvm, and remove the addprefix invocations from
> hw/$BASE_ARCH/Makefile.objs.
>
> 3) Move hw/$BASE_ARCH to target-$BASE_ARCH/hw.
>
> I think CONFIG_$BASE_ARCH is a bad idea because it violates the
> modularity that Juan introduced together with the config-devices.mak
> files.

On the contrary, I think it's the easiest way to improve our modularity.  See above.

Regards,

Anthony Liguori

>
> Paolo