[PATCH 00/18] Make common x86 arch area for i386 and x86_64 - Take 2

[Hopefully fixed email client to make it to the list this time]
[This series has changed by using git-diff -M]

Recently I've been doing some work that will affect both the i386 and x86_64
architectures. So there will be common code for both, as well as code
that will be unique for the specific arch. So I was looking into a way
to do this cleanly, and found that there is no clean way to share code
between x86_64 and i386.

What we have currently is a bunch of hacks. Seems that people can't make
up their mind to what to do.

We have hack 1.
===============

Reference code from i386 in the x86_64 Makefiles.

Examples:

therm_throt-y += ../../i386/kernel/cpu/mcheck/therm_throt.o
bootflag-y += ../../i386/kernel/bootflag.o

[tabs screwed up, because the above can't be consistant on that either]


We have hack 2.
===============

Reference code from x86_64 in the i386 Makefiles.

Examples:

k8-y += ../../x86_64/kernel/k8.o
stacktrace-y += ../../x86_64/kernel/stacktrace.o

[again the tabs too are messed up]
[--ok I'm sure I mess up the tabs too in my code--]

Now my favorite hacks!

We have hack 3.
===============

Make a sole file with just an include pointer to the i386 code.

rostedt@bilbo:~/work/git/linus.git$ cat arch/x86_64/lib/msr-on-cpu.c
#include "../../i386/lib/msr-on-cpu.c"
rostedt@bilbo:~/work/git/linus.git$

We have hack 4.
===============

Make a sole file with just an include pointer to the x86_64 code.

rostedt@bilbo:~/work/git/linus.git$ cat arch/i386/kernel/early_printk.c

#include "../../x86_64/kernel/early_printk.c"
rostedt@bilbo:~/work/git/linus.git$


So I spent last night hacking up something to try to make a common ground
for all code that is shared between x86_64 and i386. I called this

arch/x86


Seems appropriate, but I really don't care what it's called. One thing about
this name, is that typing arch/x86<Tab> doesn't tab complete x86_64 anymore.
But if you can think of something better, I'd be happy to apply it.


So the following set of patches moves common code into the arch/x86 area
and updates the i386 and x86_64 files accordingly. I separated the
patches into files that hold just Makefile changes, Kconfig changes, and
the actual moves of files.

The moves are now represted in its own patch, with one big rename patch,
using the git-diff -M format.

So the moves are simply renames, with the slight exception
of files that hold the speedstep-lib.h file. This file was moved from the
arch/i386/kerne/cpu/cpufreq directory and put into the include/asm-i386
directory. This was due to the fact that some of the moved files included
it, and some files that were not moved also included it. Instead of using
the #include "../../x86/" hack again, I just simply moved it to the global
i386 include directory. Only the arch/x86 will use the include/asm-i386
change. But to make this change the move patches of the files that contain
this change also contain the changes to reference the change to locate this
file.


With this change of having a single repo that holds both the x86_64 files
as well as the i386 code, it becomes obvious of what files are being shared.
This way we don't have to worry about someone changing a file in either
x86_64 or i386 and having it break the other arch, because they didn't
realize it was being shared.


Note: I left out all the shared pci code. It seems that this code is placed
special in the Makefiles for linking order or what not, and I don't want to
spend the time sorting that out without knowing if these changes are acceptible
or not.


-- Steve

PS. Sorry for the spam. I need to figure out how to tame quilt mail!


--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Allow user install
    ... I'd prefer that to this hack, honestly, but this hack is cool. ... Let's not reinvent the wheel here, ... Makefiles actually create directories. ... to record the symlink in the tarball instead of creating it on disk. ...
    (freebsd-arch)
  • Re: Dumme Frage zu .mp3 und .mpg
    ... Ein kruder von *BSD inspirierter Hack. ... Davon abgesehen sind die Makefiles von FreeBSD auch nur ein ... schneller Hack. ...
    (de.comp.os.unix.linux.misc)
  • Re: DBD-Oracle on AIX
    ... is a previous report for Sparc Solaris. ... The patches in the mail archive ... I expect that sparc_patch will fix your immediate problem, ... the hack to the make file or the problem with t/58object.t? ...
    (perl.dbi.users)
  • Re: IIS Hack : Anyone explain cause...
    ... This posting is provided "AS IS" with no warranties, and confers no rights. ... "Team Macromedia" wrote in message ... I can't see from the list above what if any of these patches would ... Anyone know how or why a hack like this was possible? ...
    (microsoft.public.inetserver.iis.security)
  • IIS Hack : Anyone explain cause...
    ... From a Google search it seems that this guy/unit has peformed hacks ... I can't see from the list above what if any of these patches would ... Anyone know how or why a hack like this was possible? ...
    (microsoft.public.inetserver.iis.security)