* [RFC] kbuild - introduce vdir to make life easier for x86_64
@ 2007-09-10 19:11 Sam Ravnborg
2007-09-10 19:22 ` Thomas Gleixner
2007-09-10 22:40 ` Andi Kleen
0 siblings, 2 replies; 9+ messages in thread
From: Sam Ravnborg @ 2007-09-10 19:11 UTC (permalink / raw)
To: Thomas Gleixner, Andi Kleen, LKML, kbuild devel
Hi Andi & Thomas.
One of the complaints raised about the current x86_64
Makfiles are the ugliness needed to reuse code from i386.
Andi asked me if we could do something in kbuild to make
this less ugly and below are the hack I could come up with.
The trick is that in the Makefile we tell kbuild what directory
to search for source files should we fail to locate them in
current directory. This is done by an assingment to the variable
named 'vdir' - a counterpart to make's vpath but it takes only a single
directory and not a list.
In Makefile.build I added an additional rule (see last part of the patch)
that tell kbuild that it may find the sourcefile in vdir if not
present in current dir.
This allowed me to delete some cruft from the current x86_64 makefiles.
The below are the minimal clean-up - a bit more could be done.
Comments?
This is obviously only a RFC patch - I have not even bothered to update
the documentation to describe vdir...
Sam
arch/x86_64/kernel/Makefile | 11 +----------
arch/x86_64/mm/Makefile | 3 +--
arch/x86_64/pci/Makefile | 12 +-----------
scripts/Makefile.build | 4 ++++
4 files changed, 7 insertions(+), 23 deletions(-)
diff --git a/arch/x86_64/kernel/Makefile b/arch/x86_64/kernel/Makefile
index ff5d8c9..fe58ac6 100644
--- a/arch/x86_64/kernel/Makefile
+++ b/arch/x86_64/kernel/Makefile
@@ -1,7 +1,7 @@
#
# Makefile for the linux kernel.
#
-
+vdir := arch/i386/kernel
extra-y := head.o head64.o init_task.o vmlinux.lds
EXTRA_AFLAGS := -traditional
obj-y := process.o signal.o entry.o traps.o irq.o \
@@ -49,15 +49,6 @@ obj-y += pcspeaker.o
CFLAGS_vsyscall.o := $(PROFILING) -g0
therm_throt-y += ../../i386/kernel/cpu/mcheck/therm_throt.o
-bootflag-y += ../../i386/kernel/bootflag.o
-cpuid-$(subst m,y,$(CONFIG_X86_CPUID)) += ../../i386/kernel/cpuid.o
-topology-y += ../../i386/kernel/topology.o
-microcode-$(subst m,y,$(CONFIG_MICROCODE)) += ../../i386/kernel/microcode.o
intel_cacheinfo-y += ../../i386/kernel/cpu/intel_cacheinfo.o
addon_cpuid_features-y += ../../i386/kernel/cpu/addon_cpuid_features.o
-quirks-y += ../../i386/kernel/quirks.o
-i8237-y += ../../i386/kernel/i8237.o
-msr-$(subst m,y,$(CONFIG_X86_MSR)) += ../../i386/kernel/msr.o
-alternative-y += ../../i386/kernel/alternative.o
-pcspeaker-y += ../../i386/kernel/pcspeaker.o
perfctr-watchdog-y += ../../i386/kernel/cpu/perfctr-watchdog.o
diff --git a/arch/x86_64/mm/Makefile b/arch/x86_64/mm/Makefile
index d25ac86..3d61425 100644
--- a/arch/x86_64/mm/Makefile
+++ b/arch/x86_64/mm/Makefile
@@ -1,11 +1,10 @@
#
# Makefile for the linux x86_64-specific parts of the memory manager.
#
+vdir := arch/i386/mm
obj-y := init.o fault.o ioremap.o extable.o pageattr.o mmap.o
obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
obj-$(CONFIG_NUMA) += numa.o
obj-$(CONFIG_K8_NUMA) += k8topology.o
obj-$(CONFIG_ACPI_NUMA) += srat.o
-
-hugetlbpage-y = ../../i386/mm/hugetlbpage.o
diff --git a/arch/x86_64/pci/Makefile b/arch/x86_64/pci/Makefile
index c9eddc8..84247e6 100644
--- a/arch/x86_64/pci/Makefile
+++ b/arch/x86_64/pci/Makefile
@@ -3,6 +3,7 @@
#
# Reuse the i386 PCI subsystem
#
+vdir := arch/i386/pci
EXTRA_CFLAGS += -Iarch/i386/pci
obj-y := i386.o
@@ -14,14 +15,3 @@ obj-y += legacy.o irq.o common.o early.o
obj-$(CONFIG_PCI_MMCONFIG) += mmconfig.o direct.o mmconfig-shared.o
obj-$(CONFIG_NUMA) += k8-bus.o
-
-direct-y += ../../i386/pci/direct.o
-acpi-y += ../../i386/pci/acpi.o
-legacy-y += ../../i386/pci/legacy.o
-irq-y += ../../i386/pci/irq.o
-common-y += ../../i386/pci/common.o
-fixup-y += ../../i386/pci/fixup.o
-i386-y += ../../i386/pci/i386.o
-init-y += ../../i386/pci/init.o
-early-y += ../../i386/pci/early.o
-mmconfig-shared-y += ../../i386/pci/mmconfig-shared.o
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 7fd6055..e979833 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -218,6 +218,10 @@ $(obj)/%.o: $(src)/%.c FORCE
$(call cmd,force_checksrc)
$(call if_changed_rule,cc_o_c)
+$(obj)/%.o: $(vdir)/%.c FORCE
+ $(call cmd,force_checksrc)
+ $(call if_changed_rule,cc_o_c)
+
# Single-part modules are special since we need to mark them in $(MODVERDIR)
$(single-used-m): $(obj)/%.o: $(src)/%.c FORCE
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [RFC] kbuild - introduce vdir to make life easier for x86_64
2007-09-10 19:11 [RFC] kbuild - introduce vdir to make life easier for x86_64 Sam Ravnborg
@ 2007-09-10 19:22 ` Thomas Gleixner
2007-09-10 19:29 ` Ingo Molnar
2007-09-10 22:40 ` Andi Kleen
1 sibling, 1 reply; 9+ messages in thread
From: Thomas Gleixner @ 2007-09-10 19:22 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Andi Kleen, LKML, kbuild devel, Ingo Molnar
Sam,
On Mon, 2007-09-10 at 21:11 +0200, Sam Ravnborg wrote:
> One of the complaints raised about the current x86_64
> Makfiles are the ugliness needed to reuse code from i386.
> Andi asked me if we could do something in kbuild to make
> this less ugly and below are the hack I could come up with.
while in general this is definitely a nice change, it does not really
solve the real problem of code scattered across two architectures. The
Makefile polishing is the least thing we care about.
Thanks,
tglx
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] kbuild - introduce vdir to make life easier for x86_64
2007-09-10 19:22 ` Thomas Gleixner
@ 2007-09-10 19:29 ` Ingo Molnar
2007-09-10 20:34 ` Sam Ravnborg
0 siblings, 1 reply; 9+ messages in thread
From: Ingo Molnar @ 2007-09-10 19:29 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Sam Ravnborg, Andi Kleen, LKML, kbuild devel
* Thomas Gleixner <tglx@linutronix.de> wrote:
> On Mon, 2007-09-10 at 21:11 +0200, Sam Ravnborg wrote:
> > One of the complaints raised about the current x86_64 Makfiles are
> > the ugliness needed to reuse code from i386. Andi asked me if we
> > could do something in kbuild to make this less ugly and below are
> > the hack I could come up with.
>
> while in general this is definitely a nice change, it does not really
> solve the real problem of code scattered across two architectures. The
> Makefile polishing is the least thing we care about.
>
> Thanks,
i'd like to add it here that Makefile polishing is important - it's just
that in the context of arch/*x86* the Makefile impact of the current
cross-arch code sharing practice is one of the smaller problems and the
Makefiles get cleaned up via the arch/x86 merge anyway.
Ingo
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] kbuild - introduce vdir to make life easier for x86_64
2007-09-10 19:29 ` Ingo Molnar
@ 2007-09-10 20:34 ` Sam Ravnborg
2007-09-10 20:44 ` Thomas Gleixner
0 siblings, 1 reply; 9+ messages in thread
From: Sam Ravnborg @ 2007-09-10 20:34 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Thomas Gleixner, Andi Kleen, LKML, kbuild devel
Hi Ingo
>
> i'd like to add it here that Makefile polishing is important - it's just
> that in the context of arch/*x86* the Makefile impact of the current
> cross-arch code sharing practice is one of the smaller problems and the
> Makefiles get cleaned up via the arch/x86 merge anyway.
Partly so. Took a look at the x86 tree.
The main Makefile are at least not merged. Neither are pci/Makefile not
boot/compressed/Makefile.
And some of the rest of the Makefiles are not pretty with the huge arch
specific sections ifdeffed out.
I have long thought about some extensions to the kbuild 'language'
along the following lines:
Additional shorthands for obj-m:
obj-m-if-m
obj-m-if-y
obj-m-ifn-
Additional shorthands for obj-y:
obj-y-if-m
obj-y-if-y
obj-y-ifn-
The ifn- versions are to test for empty options.
This may as an example result in following changes to the
acpi/Makefile in the merged tree:
Makefile | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kernel/acpi/Makefile b/arch/x86/kernel/acpi/Makefile
index ad4baa6..ec5a295 100644
--- a/arch/x86/kernel/acpi/Makefile
+++ b/arch/x86/kernel/acpi/Makefile
@@ -1,15 +1,11 @@
obj-$(CONFIG_ACPI) += boot.o
-ifeq ($(CONFIG_X86_32),y)
ifneq ($(CONFIG_PCI),)
-obj-$(CONFIG_X86_IO_APIC) += earlyquirk.o
-endif
-obj-$(CONFIG_ACPI_SLEEP) += sleep_32.o wakeup_32.o
-else
-obj-$(CONFIG_ACPI_SLEEP) += sleep_64.o wakeup_64.o
+obj-$(CONFIG_X86_32)-if-$(CONFIG_X86_IO_APIC) += sleep_32.o wakeup_32.o
endif
-ifneq ($(CONFIG_ACPI_PROCESSOR),)
-obj-y += cstate.o processor.o
-endif
+obj-$(CONFIG_X86_32)-if-$(CONFIG_ACPI_SLEEP) += sleep_32.o wakeup_32.o
+obj-$(CONFIG_X86_64)-if-$(CONFIG_ACPI_SLEEP) += sleep_64.o wakeup_64.o
+
+obj-y-if-$(CONFIG_ACPI_PROCESSOR) += cstate.o processor.o
My biggest worry is that we end up with a more compact format
but only me (and a very few others) can read it.
But I think the above could make the x86 Makefiles more readable
as a whole.
Sam
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [RFC] kbuild - introduce vdir to make life easier for x86_64
2007-09-10 20:34 ` Sam Ravnborg
@ 2007-09-10 20:44 ` Thomas Gleixner
0 siblings, 0 replies; 9+ messages in thread
From: Thomas Gleixner @ 2007-09-10 20:44 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Ingo Molnar, Andi Kleen, LKML, kbuild devel
Sam,
On Mon, 2007-09-10 at 22:34 +0200, Sam Ravnborg wrote:
> Partly so. Took a look at the x86 tree.
> The main Makefile are at least not merged. Neither are pci/Makefile not
> boot/compressed/Makefile.
Yeah I know. Those are the non trivial ones and the boot/compressed one
might be split forever. The pci Makefile has link order problems
(initcall order wreckage) and the main Makefile as well. Needs more
thought.
> And some of the rest of the Makefiles are not pretty with the huge arch
> specific sections ifdeffed out.
I completely agree.
> -ifneq ($(CONFIG_ACPI_PROCESSOR),)
> -obj-y += cstate.o processor.o
> -endif
> +obj-$(CONFIG_X86_32)-if-$(CONFIG_ACPI_SLEEP) += sleep_32.o wakeup_32.o
> +obj-$(CONFIG_X86_64)-if-$(CONFIG_ACPI_SLEEP) += sleep_64.o wakeup_64.o
> +
> +obj-y-if-$(CONFIG_ACPI_PROCESSOR) += cstate.o processor.o
>
>
> My biggest worry is that we end up with a more compact format
> but only me (and a very few others) can read it.
> But I think the above could make the x86 Makefiles more readable
> as a whole.
It's way better than the ifneq(...) stuff and completely understandable
at least for me. I'd like to see that change, it is helpful on a bunch
of other places in the kernel as well.
Thanks,
tglx
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] kbuild - introduce vdir to make life easier for x86_64
2007-09-10 19:11 [RFC] kbuild - introduce vdir to make life easier for x86_64 Sam Ravnborg
2007-09-10 19:22 ` Thomas Gleixner
@ 2007-09-10 22:40 ` Andi Kleen
2007-09-10 22:50 ` H. Peter Anvin
` (2 more replies)
1 sibling, 3 replies; 9+ messages in thread
From: Andi Kleen @ 2007-09-10 22:40 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Thomas Gleixner, LKML, kbuild devel
> The below are the minimal clean-up - a bit more could be done.
>
> Comments?
Looks good in principle. My only suggestion would be to name it something
differently than vdir. I know that's what GNU make calls it, but it's still
pretty cryptic. How about just fallback-dir ?
Also what would be nice (I don't know if it's doable in make) would
be a separate variable (e.g. other-obj-... := ) that contains the fallback
names and that is double checked against the fallback directory. That
would document it clearly what's going on. Failing that stuffing
them into a comment would be good at least.
-Andi
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] kbuild - introduce vdir to make life easier for x86_64
2007-09-10 22:40 ` Andi Kleen
@ 2007-09-10 22:50 ` H. Peter Anvin
2007-09-11 6:49 ` Sam Ravnborg
2007-09-11 19:42 ` Sam Ravnborg
2 siblings, 0 replies; 9+ messages in thread
From: H. Peter Anvin @ 2007-09-10 22:50 UTC (permalink / raw)
To: Andi Kleen; +Cc: Sam Ravnborg, Thomas Gleixner, LKML, kbuild devel
Andi Kleen wrote:
>> The below are the minimal clean-up - a bit more could be done.
>>
>> Comments?
>
> Looks good in principle. My only suggestion would be to name it something
> differently than vdir. I know that's what GNU make calls it, but it's still
> pretty cryptic. How about just fallback-dir ?
>
> Also what would be nice (I don't know if it's doable in make) would
> be a separate variable (e.g. other-obj-... := ) that contains the fallback
> names and that is double checked against the fallback directory. That
> would document it clearly what's going on. Failing that stuffing
> them into a comment would be good at least.
>
<nitpick>
Actually make calls it VPATH, not vdir.
-hpa
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] kbuild - introduce vdir to make life easier for x86_64
2007-09-10 22:40 ` Andi Kleen
2007-09-10 22:50 ` H. Peter Anvin
@ 2007-09-11 6:49 ` Sam Ravnborg
2007-09-11 19:42 ` Sam Ravnborg
2 siblings, 0 replies; 9+ messages in thread
From: Sam Ravnborg @ 2007-09-11 6:49 UTC (permalink / raw)
To: Andi Kleen; +Cc: Thomas Gleixner, LKML, kbuild devel
On Tue, Sep 11, 2007 at 12:40:41AM +0200, Andi Kleen wrote:
>
> > The below are the minimal clean-up - a bit more could be done.
> >
> > Comments?
>
> Looks good in principle. My only suggestion would be to name it something
> differently than vdir. I know that's what GNU make calls it, but it's still
> pretty cryptic. How about just fallback-dir ?
fallback-dir is better.
vdir came from make's vpath but then very few knows about vpath anyway so that
was not the best source of inspiration.
> Also what would be nice (I don't know if it's doable in make) would
> be a separate variable (e.g. other-obj-... := ) that contains the fallback
> names and that is double checked against the fallback directory.
My first attempt was along these lines but I dropped it for two reasons:
1) Mixing obj-y and other-obj-y assinment broke all assumptions on linkorder.
It would not be possible to link objexts in order a1.o, a2.o, a3.o if a1.o
and a3.o were assigned to obj-y and a2.o was assigned to other-obj-y.
2) It needed a decent amouth of unreadable gmake-foo to introduce
a second variable. And the learning curve for kbuild internals are alreay
to steep so I try to avoid additional complexity.
I'm a bit reluctant to just enable the fallback-dir functionality.
There is no point in adding this for the sake of x86 if we merge
i386 and x86_64 a few days after.
Sam
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] kbuild - introduce vdir to make life easier for x86_64
2007-09-10 22:40 ` Andi Kleen
2007-09-10 22:50 ` H. Peter Anvin
2007-09-11 6:49 ` Sam Ravnborg
@ 2007-09-11 19:42 ` Sam Ravnborg
2 siblings, 0 replies; 9+ messages in thread
From: Sam Ravnborg @ 2007-09-11 19:42 UTC (permalink / raw)
To: Andi Kleen; +Cc: Thomas Gleixner, LKML, kbuild devel
On Tue, Sep 11, 2007 at 12:40:41AM +0200, Andi Kleen wrote:
>
> > The below are the minimal clean-up - a bit more could be done.
> >
> > Comments?
>
> Looks good in principle. My only suggestion would be to name it something
> differently than vdir. I know that's what GNU make calls it, but it's still
> pretty cryptic. How about just fallback-dir ?
>
> Also what would be nice (I don't know if it's doable in make) would
> be a separate variable (e.g. other-obj-... := ) that contains the fallback
> names and that is double checked against the fallback directory. That
> would document it clearly what's going on. Failing that stuffing
> them into a comment would be good at least.
I did not like the vdir hack for a couple of reasons as partly outline by Andi.
So starting to wonder why the obvious did not work.
For mm/Makefile I wanted to do:
diff --git a/arch/x86_64/mm/Makefile b/arch/x86_64/mm/Makefile
index d25ac86..6f4addf 100644
--- a/arch/x86_64/mm/Makefile
+++ b/arch/x86_64/mm/Makefile
@@ -1,11 +1,10 @@
#
# Makefile for the linux x86_64-specific parts of the memory manager.
#
+i386 := ../../../arch/i386/mm
obj-y := init.o fault.o ioremap.o extable.o pageattr.o mmap.o
-obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
+obj-$(CONFIG_HUGETLB_PAGE) += $(i386)/hugetlbpage.o
obj-$(CONFIG_NUMA) += numa.o
obj-$(CONFIG_K8_NUMA) += k8topology.o
obj-$(CONFIG_ACPI_NUMA) += srat.o
-
-hugetlbpage-y = ../../i386/mm/hugetlbpage.o
And after wondering a bit I came up with following fix for kbuild:
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index fc498fe..ff03b15 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -46,7 +46,7 @@ multi-objs := $(multi-objs-y) $(multi-objs-m)
# $(subdir-obj-y) is the list of objects in $(obj-y) which do not live
# in the local directory
-subdir-obj-y := $(foreach o,$(obj-y),$(if $(filter-out $(o),$(notdir $(o))),$(o)))
+subdir-obj-y := $(filter %/built-in.o, $(obj-y))
# $(obj-dirs) is a list of directories that contain object files
obj-dirs := $(dir $(multi-objs) $(subdir-obj-y))
subdir-obj-y listed all targets in another dir than current dir
but only needed to list built-in.o targets.
So after fixig this long standing bug in kbuild I could do the attached
cleanup of current x86_64 Makefiles.
I will push the kbuild fix in next merge window but due to the ongoing
merge talk I dunno about the x86_64 patch.
Anyway the kbuild fix needs to be pushed first.
Sam
arch/x86_64/kernel/Makefile | 37 +++++++++++-------------------------
arch/x86_64/kernel/acpi/Makefile | 12 ++++-------
arch/x86_64/kernel/cpufreq/Makefile | 18 +++++------------
arch/x86_64/mm/Makefile | 5 +---
arch/x86_64/pci/Makefile | 24 ++++++-----------------
scripts/Makefile.lib | 2 -
6 files changed, 33 insertions(+), 65 deletions(-)
diff --git a/arch/x86_64/kernel/Makefile b/arch/x86_64/kernel/Makefile
index ff5d8c9..ac27cc4 100644
--- a/arch/x86_64/kernel/Makefile
+++ b/arch/x86_64/kernel/Makefile
@@ -1,25 +1,26 @@
#
# Makefile for the linux kernel.
#
+i386 := ../../../arch/i386/kernel
extra-y := head.o head64.o init_task.o vmlinux.lds
EXTRA_AFLAGS := -traditional
obj-y := process.o signal.o entry.o traps.o irq.o \
ptrace.o time.o ioport.o ldt.o setup.o i8259.o sys_x86_64.o \
x8664_ksyms.o i387.o syscall.o vsyscall.o \
- setup64.o bootflag.o e820.o reboot.o quirks.o i8237.o \
- pci-dma.o pci-nommu.o alternative.o hpet.o tsc.o bugs.o \
- perfctr-watchdog.o
+ setup64.o $(i386)/bootflag.o e820.o reboot.o $(i386)/quirks.o $(i386)/i8237.o \
+ pci-dma.o pci-nommu.o $(i386)/alternative.o hpet.o tsc.o bugs.o \
+ $(i386)/cpu/perfctr-watchdog.o
obj-$(CONFIG_STACKTRACE) += stacktrace.o
-obj-$(CONFIG_X86_MCE) += mce.o therm_throt.o
+obj-$(CONFIG_X86_MCE) += mce.o $(i386)/cpu/mcheck/therm_throt.o
obj-$(CONFIG_X86_MCE_INTEL) += mce_intel.o
obj-$(CONFIG_X86_MCE_AMD) += mce_amd.o
obj-$(CONFIG_MTRR) += ../../i386/kernel/cpu/mtrr/
obj-$(CONFIG_ACPI) += acpi/
-obj-$(CONFIG_X86_MSR) += msr.o
-obj-$(CONFIG_MICROCODE) += microcode.o
-obj-$(CONFIG_X86_CPUID) += cpuid.o
+obj-$(CONFIG_X86_MSR) += $(i386)/msr.o
+obj-$(CONFIG_MICROCODE) += $(i386)/microcode.o
+obj-$(CONFIG_X86_CPUID) += $(i386)/cpuid.o
obj-$(CONFIG_SMP) += smp.o smpboot.o trampoline.o tsc_sync.o
obj-y += apic.o nmi.o
obj-y += io_apic.o mpparse.o genapic.o genapic_flat.o
@@ -41,23 +42,9 @@ obj-$(CONFIG_AUDIT) += audit.o
obj-$(CONFIG_MODULES) += module.o
obj-$(CONFIG_PCI) += early-quirks.o
-obj-y += topology.o
-obj-y += intel_cacheinfo.o
-obj-y += addon_cpuid_features.o
-obj-y += pcspeaker.o
+obj-y += $(i386)/topology.o
+obj-y += $(i386)/cpu/intel_cacheinfo.o
+obj-y += $(i386)/cpu/addon_cpuid_features.o
+obj-y += $(i386)/pcspeaker.o
CFLAGS_vsyscall.o := $(PROFILING) -g0
-
-therm_throt-y += ../../i386/kernel/cpu/mcheck/therm_throt.o
-bootflag-y += ../../i386/kernel/bootflag.o
-cpuid-$(subst m,y,$(CONFIG_X86_CPUID)) += ../../i386/kernel/cpuid.o
-topology-y += ../../i386/kernel/topology.o
-microcode-$(subst m,y,$(CONFIG_MICROCODE)) += ../../i386/kernel/microcode.o
-intel_cacheinfo-y += ../../i386/kernel/cpu/intel_cacheinfo.o
-addon_cpuid_features-y += ../../i386/kernel/cpu/addon_cpuid_features.o
-quirks-y += ../../i386/kernel/quirks.o
-i8237-y += ../../i386/kernel/i8237.o
-msr-$(subst m,y,$(CONFIG_X86_MSR)) += ../../i386/kernel/msr.o
-alternative-y += ../../i386/kernel/alternative.o
-pcspeaker-y += ../../i386/kernel/pcspeaker.o
-perfctr-watchdog-y += ../../i386/kernel/cpu/perfctr-watchdog.o
diff --git a/arch/x86_64/kernel/acpi/Makefile b/arch/x86_64/kernel/acpi/Makefile
index 080b996..7879f97 100644
--- a/arch/x86_64/kernel/acpi/Makefile
+++ b/arch/x86_64/kernel/acpi/Makefile
@@ -1,9 +1,7 @@
-obj-y := boot.o
-boot-y := ../../../i386/kernel/acpi/boot.o
-obj-$(CONFIG_ACPI_SLEEP) += sleep.o wakeup.o
+i386 := ../../../../arch/i386/kernel/acpi
-ifneq ($(CONFIG_ACPI_PROCESSOR),)
-obj-y += processor.o
-processor-y := ../../../i386/kernel/acpi/processor.o ../../../i386/kernel/acpi/cstate.o
-endif
+obj-y := $(i386)/boot.o
+obj-$(CONFIG_ACPI_SLEEP) += sleep.o wakeup.o
+obj-$(CONFIG_ACPI_PROCESSOR) += $(i386)/processor.o
+obj-$(CONFIG_ACPI_PROCESSOR) += $(i386)/cstate.o
diff --git a/arch/x86_64/kernel/cpufreq/Makefile b/arch/x86_64/kernel/cpufreq/Makefile
index 753ce1d..d8dacae 100644
--- a/arch/x86_64/kernel/cpufreq/Makefile
+++ b/arch/x86_64/kernel/cpufreq/Makefile
@@ -2,16 +2,10 @@
# Reuse the i386 cpufreq drivers
#
-SRCDIR := ../../../i386/kernel/cpu/cpufreq
+i386 := ../../../i386/kernel/cpu/cpufreq
-obj-$(CONFIG_X86_POWERNOW_K8) += powernow-k8.o
-obj-$(CONFIG_X86_ACPI_CPUFREQ) += acpi-cpufreq.o
-obj-$(CONFIG_X86_SPEEDSTEP_CENTRINO) += speedstep-centrino.o
-obj-$(CONFIG_X86_P4_CLOCKMOD) += p4-clockmod.o
-obj-$(CONFIG_X86_SPEEDSTEP_LIB) += speedstep-lib.o
-
-powernow-k8-objs := ${SRCDIR}/powernow-k8.o
-speedstep-centrino-objs := ${SRCDIR}/speedstep-centrino.o
-acpi-cpufreq-objs := ${SRCDIR}/acpi-cpufreq.o
-p4-clockmod-objs := ${SRCDIR}/p4-clockmod.o
-speedstep-lib-objs := ${SRCDIR}/speedstep-lib.o
+obj-$(CONFIG_X86_POWERNOW_K8) += $(i386)/powernow-k8.o
+obj-$(CONFIG_X86_ACPI_CPUFREQ) += $(i386)/acpi-cpufreq.o
+obj-$(CONFIG_X86_SPEEDSTEP_CENTRINO) += $(i386)/speedstep-centrino.o
+obj-$(CONFIG_X86_P4_CLOCKMOD) += $(i386)/p4-clockmod.o
+obj-$(CONFIG_X86_SPEEDSTEP_LIB) += $(i386)/speedstep-lib.o
diff --git a/arch/x86_64/mm/Makefile b/arch/x86_64/mm/Makefile
index d25ac86..6f4addf 100644
--- a/arch/x86_64/mm/Makefile
+++ b/arch/x86_64/mm/Makefile
@@ -1,11 +1,10 @@
#
# Makefile for the linux x86_64-specific parts of the memory manager.
#
+i386 := ../../../arch/i386/mm
obj-y := init.o fault.o ioremap.o extable.o pageattr.o mmap.o
-obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
+obj-$(CONFIG_HUGETLB_PAGE) += $(i386)/hugetlbpage.o
obj-$(CONFIG_NUMA) += numa.o
obj-$(CONFIG_K8_NUMA) += k8topology.o
obj-$(CONFIG_ACPI_NUMA) += srat.o
-
-hugetlbpage-y = ../../i386/mm/hugetlbpage.o
diff --git a/arch/x86_64/pci/Makefile b/arch/x86_64/pci/Makefile
index c9eddc8..6f69df2 100644
--- a/arch/x86_64/pci/Makefile
+++ b/arch/x86_64/pci/Makefile
@@ -3,25 +3,15 @@
#
# Reuse the i386 PCI subsystem
#
+i386 := ../../../arch/i386/pci
EXTRA_CFLAGS += -Iarch/i386/pci
-obj-y := i386.o
-obj-$(CONFIG_PCI_DIRECT)+= direct.o
-obj-y += fixup.o init.o
-obj-$(CONFIG_ACPI) += acpi.o
-obj-y += legacy.o irq.o common.o early.o
+obj-y := $(i386)/i386.o
+obj-$(CONFIG_PCI_DIRECT)+= $(i386)/direct.o
+obj-y += $(i386)/fixup.o init.o
+obj-$(CONFIG_ACPI) += $(i386)/acpi.o
+obj-y += $(i386)/legacy.o $(i386)/irq.o $(i386)/common.o $(i386)/early.o
# mmconfig has a 64bit special
-obj-$(CONFIG_PCI_MMCONFIG) += mmconfig.o direct.o mmconfig-shared.o
+obj-$(CONFIG_PCI_MMCONFIG) += mmconfig.o $(i386)/direct.o $(i386)/mmconfig-shared.o
obj-$(CONFIG_NUMA) += k8-bus.o
-
-direct-y += ../../i386/pci/direct.o
-acpi-y += ../../i386/pci/acpi.o
-legacy-y += ../../i386/pci/legacy.o
-irq-y += ../../i386/pci/irq.o
-common-y += ../../i386/pci/common.o
-fixup-y += ../../i386/pci/fixup.o
-i386-y += ../../i386/pci/i386.o
-init-y += ../../i386/pci/init.o
-early-y += ../../i386/pci/early.o
-mmconfig-shared-y += ../../i386/pci/mmconfig-shared.o
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index fc498fe..ff03b15 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -46,7 +46,7 @@ multi-objs := $(multi-objs-y) $(multi-objs-m)
# $(subdir-obj-y) is the list of objects in $(obj-y) which do not live
# in the local directory
-subdir-obj-y := $(foreach o,$(obj-y),$(if $(filter-out $(o),$(notdir $(o))),$(o)))
+subdir-obj-y := $(filter %/built-in.o, $(obj-y))
# $(obj-dirs) is a list of directories that contain object files
obj-dirs := $(dir $(multi-objs) $(subdir-obj-y))
^ permalink raw reply related [flat|nested] 9+ messages in thread
end of thread, other threads:[~2007-09-11 19:41 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-09-10 19:11 [RFC] kbuild - introduce vdir to make life easier for x86_64 Sam Ravnborg
2007-09-10 19:22 ` Thomas Gleixner
2007-09-10 19:29 ` Ingo Molnar
2007-09-10 20:34 ` Sam Ravnborg
2007-09-10 20:44 ` Thomas Gleixner
2007-09-10 22:40 ` Andi Kleen
2007-09-10 22:50 ` H. Peter Anvin
2007-09-11 6:49 ` Sam Ravnborg
2007-09-11 19:42 ` Sam Ravnborg
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox