From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48707) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Shh6B-0005sv-80 for qemu-devel@nongnu.org; Thu, 21 Jun 2012 09:07:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Shh68-0001lm-Al for qemu-devel@nongnu.org; Thu, 21 Jun 2012 09:06:58 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:41194) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Shh68-0001l9-47 for qemu-devel@nongnu.org; Thu, 21 Jun 2012 09:06:56 -0400 Received: by pbbro12 with SMTP id ro12so2152286pbb.4 for ; Thu, 21 Jun 2012 06:06:52 -0700 (PDT) Message-ID: <4FE31C6A.20207@codemonkey.ws> Date: Thu, 21 Jun 2012 08:06:50 -0500 From: Anthony Liguori MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] build: introduce target CONFIG_ variables and use them for kvm List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Peter Maydell , qemu-devel@nongnu.org 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