That would work, but there's a few alternatives that I think would work
even better.
The downside with what you suggest is that I'd like the arch-specific
include files to be clearly separated (ie I think the naming should be
"something/include/something", which makes things clearer.
Also, I hate how doing '-Iarch/$(ARCH)' would basically make any random
arch/xyz/ subdirectory be a potential location for a header file. I'd hate
for the include-path to contain subdirectories that simply aren't meant
for that (ie #include <kernel/tls.h> would now quite by mistake find the
*private* header file in arch/x86/kernel/tls.h that was never meant to be
generally visible!)
So the trivial alternative is to just do
git mv include/asm-xyz arch/xyz/include
and keep the symlink that we already set up (just make it point to
arch/xyz/include instead of include/asm-xyz). That is conceptually the
smallest change.
But the alternative I'd actually *prefer* would avoid the symlink, and
would be roughly:
for i in $(arch-list)
do
mkdir arch/$i/include
git mv include/asm-$i arch/$i/asm
done
git mv include/asm-generic include/asm
and then remove the symlink to asm entirely, and instead add a
-Iarch/xyz/include, and put that as the *first* entry in the include path.
This would mean that:
- no symlink games
- if some architecture just uses the generic header file, it doesn't need
to do anything: it just wouldn't implement that header file at all, and
the next entry in the search-path would just find the generic
include/asm entry.
I dunno. It's not a huge deal, but it really would be nice to have all the
arch/xyz code together for diffstat's etc.
Linus
--
