qemu-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]