[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] build: introduce target CONFIG_ variables and u
From: |
Anthony Liguori |
Subject: |
Re: [Qemu-devel] [PATCH] build: introduce target CONFIG_ variables and use them for kvm |
Date: |
Thu, 21 Jun 2012 08:06:50 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 |
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