Hi Paul. Now that kbuild has proper support for include/$ARCH/* maybe this is a good time to kill the use of symlinks for sh? The idea is to do the following: 1) move all cpu specific directories to: arch/sh/include/$CPU/cpu then we can continue to use "#include <cpu/foo.h>" if we just tell gcc to pick up include files in the correct directory. 2) move all mach specific directories to: arch/sh/$ARCH/mach then we can continue to use "#include <mach/foo.h> But this does NOT address the mach's that relied on the mach symlink that pointed one level below. I do not know how big his issue is. 3) move remaining header files to arch/sh/include/asm 4) adjust arch/sh/Makefile Test and enjoy.... I do not have sh toolchina on this box so I have not tried to do a full patch myself. And the mach stuff obviously worries me with the link to the parent directory. But apart form this is is simple. See below for my take on it. You can put an Signed-off-by: Sam Ravnborg <firstname.lastname@example.org> or Acked-by: Sam Ravnborg <email@example.com> as you like on the final patch. Questions / comments are welcome. PS. sparc is the first to use arch/$ARCH/include and will hit -linus soon, Sam To complete step 1) to 3) the following script can be used: # CPU dirs mkdir -p arch/sh/include/cpu-sh2/cpu mkdir -p arch/sh/include/cpu-sh2a/cpu mkdir -p arch/sh/include/cpu-sh3/cpu mkdir -p arch/sh/include/cpu-sh4/cpu mkdir -p arch/sh/include/cpu-sh5/cpu git mv include/asm-sh/cpu-sh2 arch/sh/include/cpu-sh2/cpu git mv include/asm-sh/cpu-sh2a arch/sh/include/cpu-sh2a/cpu git mv include/asm-sh/cpu-sh3 arch/sh/include/cpu-sh3/cpu git mv include/asm-sh/cpu-sh4 arch/sh/include/cpu-sh4/cpu git mv include/asm-sh/cpu-sh5 arch/sh/include/cpu-sh5/cpu # mach dirs mkdir -p arch/sh/include/dreamcast/mach mkdir -p arch/sh/include/landisk/mach mkdir -p arch/sh/include/hd64465/mach mkdir -p arch/sh/include/sh03/mach git mv include/asm-sh/dreamcast ...
Hi Sam, Good idea, I just saw the sparc change go by earlier today and remembered This didn't end up being _too_ painful, though it did take a bit of time to hunt down all of the guilty parties. I've pushed out what I have now, which you can see at: http://git.kernel.org/?p=linux/kernel/git/lethal/sh-2.6.git;a=commitdiff;h=f15cbe6f1a4... It's been holding up to all of the random builds I've thrown at it so far, so there shouldn't be any really nasty surprises left over. I'm glad git supports renames.. :-) --
I took a quick look at it and the header re-org looks good. I like that you added the 'mach-' prefix to the directory names. But I also noticed several changes like this: -#include <asm/landisk/iodata_landisk.h> +#include <mach/iodata_landisk.h> In this case you _know_ that this is a landisk so the less magic option would have been the longer include form like this: +#include <mach-landisk/mach/iodata_landisk.h> It would be preferable that we use the gcc -I directive: -Iarch/sh/include/mach-$MACH only to automagically select between identical named files for the different platforms and not like the above where we use it simply to cut off the include path a little. Another note is that you decided to move the generated file over to arch/sh/include too. I really do not know if I think this is the right approach. What I like is that we some day end up with generated files in a common place. But I have not really thought it through and thus I have no final idea how to do it. So in other words - keep it as is and lets re-visit it should we one day decide to do this in a common way across architectures. Thanks for looking into this so quickly! Sam --
Yes, I had thought about that as well. We certainly need to go this route if we are building multiple mach types at the same time. Fortunately the vast majority of mach types do not have their own include structure, so This was before I realized that asm-offsets.h was being placed in include/asm-sh anyways, despite the directory not existing until Kbuild created it. I don't have any problems with moving it back, I just thought the idea of multiple include directories for the same asm/ prefix seemed non-intuitive. --