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 <sam@ravnborg.org>
or
Acked-by: Sam Ravnborg <sam@ravnborg.org>

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 ...
[ message continues ]

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.. :-)
--

[ message continues ]

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

[ message continues ]

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.
--

[ message continues ]