Summit support for pcibus <-> cpumask topology

This patch adds a new file, arch/i386/kernel/summit.c, for summit-specific code. Adds some structures to mach_mpparse.h. Also adds a hook in setup_arch() to dig out the PCI info, and stores it in the mp_bus_id_to_node[] array, where it can be read by the topology functions.

Quoted 2 lines

This patch adds a new file, arch/i386/kernel/summit.c, for summit-specific code. Adds some structures to mach_mpparse.h. Also adds a hook in setup_arch() to dig out the PCI info, and stores it in the mp_bus_id_to_node[] array, where it can be read by the topology functions.

Wouldn't this file be better in arch/i386/mach-summit in keeping with all the other subarch stuff?

While you're creating a separate file for summit, could you move the summit specific variables (mpparse.c:x86_summit is the only one, I think) into it so we can clean all the summit references out of the main line?

Thanks,

James

Quoted 1 line

This patch adds a new file, arch/i386/kernel/summit.c, for summit-specific code. Adds some structures to mach_mpparse.h. Also adds a hook in setup_arch() to dig out the PCI info, and stores it in the mp_bus_id_to_node[] array, where it can be read by the topology functions.

Wouldn't this file be better in arch/i386/mach-summit in keeping with all the other subarch stuff?

While you're creating a separate file for summit, could you move the summit specific variables (mpparse.c:x86_summit is the only one, I think) into it so we can clean all the summit references out of the main line?

Thanks,

James

Quoted 1 line

This patch adds a new file, arch/i386/kernel/summit.c, for summit-specific code. Adds some structures to mach_mpparse.h. Also adds a hook in setup_arch() to dig out the PCI info, and stores it in the mp_bus_id_to_node[] array, where it can be read by the topology functions.

Wouldn't this file be better in arch/i386/mach-summit in keeping with all the other subarch stuff?

While you're creating a separate file for summit, could you move the summit specific variables (mpparse.c:x86_summit is the only one, I think) into it so we can clean all the summit references out of the main line?

Thanks,

James

Quoted 14 lines

Quoted 5 lines

This patch adds a new file, arch/i386/kernel/summit.c, for summit-specific code. Adds some structures to mach_mpparse.h. Also adds a hook in setup_arch() to dig out the PCI info, and stores it in the mp_bus_id_to_node[] array, where it can be read by the topology functions.

Wouldn't this file be better in arch/i386/mach-summit in keeping with all the other subarch stuff?

While you're creating a separate file for summit, could you move the summit specific variables (mpparse.c:x86_summit is the only one, I think) into it so we can clean all the summit references out of the main line?

Quoted 3 lines

Thanks,

James

While I was at it, I subarchified (I'll cc Websters with the new word ;) numaq as well. Copied mach-defaults setup.c, topology.c, and Makefile. Moved arch/i386/kernel/numaq.c into mach-numaq. Compiles.

No, *please* don't do this. Subarch for .c files is *broken*.

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.

Let's just stick with your original patch - it's fine.

Quoted 1 line

No, *please* don't do this. Subarch for .c files is *broken*.

It is the place designed for code belonging only to one subarch.

Quoted 1 line

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.

It is the place designed for code belonging only to one subarch.

Quoted 3 lines

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.

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 $< $@

Quoted 5 lines

It is the place designed for code belonging only to one subarch.

Quoted 3 lines

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.

I agree that duplicating files into different subarch dirs sure isn't the way to go.

Quoted 4 lines

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

I think VPATH has never been meant to be used for anything like this, it could be make to work, though it would interfere with the separate src/obj thing. But I don't think it's a good idea, we'll have object files magically appear without any visible source file, that's just too obscure.

I can basically see two options at this point:

Quoted 2 lines

$(obj)/setup.c: $(src)/../mach-default/setup.c

	cat $< $@

Something like this, but using ln -sf would be nicer, since that avoids someone editing the wrong file by mistake.

I think VPATH has never been meant to be used for anything like this, it could be make to work, though it would interfere with the separate src/obj thing. But I don't think it's a good idea, we'll have object files magically appear without any visible source file, that's just too obscure.

Quoted 4 lines · Kai Germaschewski

I think VPATH has never been meant to be used for anything like this, it could be make to work, though it would interfere with the separate src/obj thing. But I don't think it's a good idea, we'll have object files magically appear without any visible source file, that's just too obscure.

Well...There is a slightly different solution.

What if the summit/numaq setup.c simply contained

#include "../mach-default/setup.c"

?

Not that I like doing this, but it solves the "magic" appearace of the object file and it's perfectly clear to anyone editing the file where it really comes from.

No, *please* don't do this. Subarch for .c files is *broken*. 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.

Quoted 4 lines

No, *please* don't do this. Subarch for .c files is *broken*. 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 was fixed in about 2.5.50-ac. I thought Linus had picked up the improved version of mach-default* too. Its used extensively for stuff like PC9800 which is deeply un-PC

It was fixed in about 2.5.50-ac. I thought Linus had picked up the improved version of mach-default* too. Its used extensively for stuff like PC9800 which is deeply un-PC

Quoted 10 lines

Quoted 10 lines

Quoted 1 line

This patch adds a new file, arch/i386/kernel/summit.c, for summit-specific code. Adds some structures to mach_mpparse.h. Also adds a hook in setup_arch() to dig out the PCI info, and stores it in the mp_bus_id_to_node[] array, where it can be read by the topology functions.

Wouldn't this file be better in arch/i386/mach-summit in keeping with all the other subarch stuff?

While you're creating a separate file for summit, could you move the summit specific variables (mpparse.c:x86_summit is the only one, I think) into it so we can clean all the summit references out of the main line?

Quoted 5 lines

Quoted 3 lines

Thanks,

James

While I was at it, I subarchified (I'll cc Websters with the new word ;) numaq as well. Copied mach-defaults setup.c, topology.c, and Makefile. Moved arch/i386/kernel/numaq.c into mach-numaq. Compiles.

No, *please* don't do this. Subarch for .c files is *broken*.

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.

Let's just stick with your original patch - it's fine.

M.

I'm inclined to agree with Martin on this one. The useless code duplication is outright stupidity. Makefile hackery would work, as would James' suggestion of #include'ing the .c files. I tend to agree with his assessment of that as the least of evils. But until we have a good way of falling back to mach-default for .c files, I'm going to leave the one (relatively) small .c file in arch/i386/kernel. It will be trivial to move it later, and for now it sits nicely next to it's
kin: arch/i386/kernel/numaq.c.

diff -Nur --exclude-from=/usr/src/.dontdiff linux-2.5.65-vanilla/arch/i386/kernel/setup.c linux-2.5.65-summit_pcimap/arch/i386/kernel/setup.c

arch/i386/kernel/setup.c +3 -0

@@ -939,6 +939,9 @@
 	if (smp_found_config)
 		get_smp_config();
 #endif
+#ifdef CONFIG_X86_SUMMIT
+	setup_summit();
+#endif
 
 	register_memory(max_low_pfn);
 

All in all, properly done, there would be very little code duplication even for something as PC like as the summit.

If I read correctly between the whines, the real issue is that subarch is used to support things that vary from uniquely oddball to extremely weird and are all ancient and highly unlikely ever to be found in nature. IBM, understandably, doesn't want its brand new and expensive summit lumped with such company.