It is the place designed for code belonging only to one subarch.
> Last time I looked (and I don't think anyone has fixed it since)
> it requires copying files all over the place, making an unmaintainable
> nightmare. Either subarch needs fixing first, or we don't use it.
It's design is identical to the arch directories, except that it has far
fewer hooks. People grumble about having to change 20 arch files when
they want to alter the interface, but no-one's yet called it
unmaintainable.
The subarch split is designed to support machines with radically
different architectures like voyager and to a lesser extent visws. Just
because summit isn't a radically different architecture doesn't make the
subarch concept broken. I think other people have mentioned before that
what you probably need for summit is a modular apic driver. However, if
you want to propose changes to the subarch setup, you're welcome to do
that too.
The problem you have (your setup.c and topology.c are identical to the
default) was originally going to be solved using VPATH. Unfortunately,
that got broken along the way in the new build scheme, so the best I
think you can do is add this to the summit Makefile
$(obj)/setup.c: $(src)/../mach-default/setup.c
cat $< $@
etc.
Kai isn't going to like this, but hopefully he will be able to come up
with a better solution.
However, you could also take this opportunity to remove the NUMA
pollution from mach-generic/topology.c.
> Let's just stick with your original patch - it's fine.
No, it's not. The object of the subarch is to remove all subarch
specific files from the main i386/kernel directory.
James
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/