Merge headerfiles for m68k and m68knommu to arch/m68k/include/asm

Merge headerfiles for m68k and m68knommu to arch/m68k/include/asm

[Sam Ravnborg]

[this mail is cross posted to uclinux mailing list which is subscriber only]

Following is a pseudo patch (a script + a patch) that merges
the include files for m68k and m68knommu in one place at:

    arch/m68k/include/asm

The script was written by Arnd and I added a few modifications.

The scripts does the following:

1) move all header files from include/asm-m68k to arch/m68k/include/asm
2) delete all header files in arch/m68knommu/include/asm that are equal
3) copy all unique files from arch/m68knommu/include/asm to m68k
4) merge the reminaing files using a small helper .h files.

The original m68k file is named <file>_mm.h  [mm for memory manager]
The m68knommu file is named <file>_no.h [no for no memory manager]

I have used the following include guard:

#ifdef __uClinux__
#include "atomic_no.h"
#else
#include "atomic_mm.h"
#endif

gcc -E -dM for the two compilers revealed that this was the
only symbol that differed.

With the above construct we do the "right thing" also for
headers exported to userspace.
But actually none of the headers using the above are
subject for export at the moment so we could use a
CONFIG_ symbol for the same.

The script assumes the repository is kept in git and shall be
executed in the root of the kernel source.

Originally we developed support for sharing same set of header files
between two architectures for sparc. So only a minimal patch is
needed in the top-level Makefile which is now a good thing for m68k.

I have tested the following:
- a defconfig build for m68k [partly - I lost patience]
- a allnoconfig build for m68knommu
- headers_check for m68k
- headers_check for m68knommu

To merge the header files run the script and then apply the patch.
The patch has my:
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>

I looked at doing this in smaller steps but that
was not doable. And using the script it is anyway a simple
operation to do.

I hope you m68k* guys accept a two step approach where we
merge header files before source code.
Note: we just completed merge of sparc and sparc64 and it
was a painless experience to do so so do not be scared.

Note: the part touching the top-level Makefile will conflict
with some pending sparc changes. But this is trivial to fix.
Or just beat sparc and get this in first :-)

	Sam


Script:
TARGET=arch/m68k/include/asm
SOURCE=arch/m68knommu/include/asm

# files that just do a simple include of the m68k variant
INCLUDE="cachectl.h errno.h fcntl.h hwtest.h ioctls.h ipcbuf.h \
linkage.h math-emu.h md.h mman.h movs.h msgbuf.h openprom.h \
oplib.h poll.h posix_types.h resource.h rtc.h sembuf.h shmbuf.h \
shm.h shmparam.h socket.h sockios.h spinlock.h statfs.h stat.h \
termbits.h termios.h tlb.h types.h user.h"

# files are equal or only include guards differ
EQUAL="auxvec.h cputime.h device.h emergency-restart.h futex.h \
ioctl.h irq_regs.h kdebug.h local.h mutex.h percpu.h \
sections.h topology.h"

# only in nommu68k
NOMUUFILES="anchor.h bootstd.h coldfire.h commproc.h dbg.h \
elia.h flat.h m5206sim.h m520xsim.h m523xsim.h m5249sim.h \
m5272sim.h m527xsim.h m528xsim.h m5307sim.h m532xsim.h \
m5407sim.h m68360_enet.h m68360.h m68360_pram.h m68360_quicc.h \
m68360_regs.h MC68328.h MC68332.h MC68EZ328.h MC68VZ328.h \
mcfcache.h mcfdma.h mcfmbus.h mcfne.h mcfpci.h mcfpit.h \
mcfsim.h mcfsmc.h mcftimer.h mcfuart.h mcfwdebug.h \
nettel.h quicc_simple.h smp.h"

# files that differ
FILES="atomic.h bitops.h bootinfo.h bug.h bugs.h byteorder.h cache.h \
cacheflush.h checksum.h current.h delay.h div64.h \
dma-mapping.h dma.h elf.h entry.h fb.h fpu.h hardirq.h hw_irq.h io.h \
irq.h kmap_types.h machdep.h mc146818rtc.h mmu.h mmu_context.h \
module.h page.h page_offset.h param.h pci.h pgalloc.h \
pgtable.h processor.h ptrace.h scatterlist.h segment.h \
setup.h sigcontext.h siginfo.h signal.h string.h system.h \
thread_info.h timex.h tlbflush.h traps.h uaccess.h ucontext.h \
unaligned.h unistd.h"

mergefile() {
	BASE=${1%.h}
	git mv ${SOURCE}/$1 ${TARGET}/${BASE}_no.h
	git mv ${TARGET}/$1 ${TARGET}/${BASE}_mm.h

cat << EOF > ${TARGET}/$1
#ifdef __uClinux__
#include "${BASE}_no.h"
#else
#include "${BASE}_mm.h"
#endif
EOF

	git add ${TARGET}/$1
}

#catch bugs in script
set -e

mkdir -p ${TARGET}

# move all m68k header files
git mv include/asm-m68k/* ${TARGET}
rmdir include/asm-m68k

# Kbuild n m68knommu is no longer needed - the m68k variant has it all
git rm ${SOURCE}/Kbuild
# Files that are equal or just include the m68k variant can be deleted
for F in $INCLUDE $EQUAL; do
	git rm ${SOURCE}/$F
done

# Files that are unique for m68knommu can be moved
for F in $NOMUUFILES; do
	git mv ${SOURCE}/$F ${TARGET}/$F
done

# merge the incompatible files
for F in $FILES ; do
	mergefile $F
done

#directory should be empty now - remove it (and fail if not empty)
rmdir arch/m68knommu/include/asm
rmdir arch/m68knommu/include




Patch:
diff --git a/Makefile b/Makefile
index 9a49960..fa5a33d 100644
--- a/Makefile
+++ b/Makefile
@@ -211,6 +211,9 @@ ifeq ($(ARCH),sparc64)
 else
        hdr-arch  := $(SRCARCH)
 endif
+ifeq ($(ARCH),m68knommu)
+       hdr-arch  := m68k
+endif
 
 KCONFIG_CONFIG	?= .config
 
diff --git a/arch/m68k/include/asm/pci_no.h b/arch/m68k/include/asm/pci_no.h
index a13f3cc..9abbc03 100644
--- a/arch/m68k/include/asm/pci_no.h
+++ b/arch/m68k/include/asm/pci_no.h
@@ -1,7 +1,7 @@
 #ifndef M68KNOMMU_PCI_H
 #define	M68KNOMMU_PCI_H
 
-#include <asm-m68k/pci.h>
+#include <asm/pci_mm.h>
 
 #ifdef CONFIG_COMEMPCI
 /*
diff --git a/arch/m68k/include/asm/setup_no.h b/arch/m68k/include/asm/setup_no.h
index fb86bb2..45d286c 100644
--- a/arch/m68k/include/asm/setup_no.h
+++ b/arch/m68k/include/asm/setup_no.h
@@ -1,6 +1,6 @@
 #ifdef __KERNEL__
 
-#include <asm-m68k/setup.h>
+#include <asm/setup_mm.h>
 
 /* We have a bigger command line buffer. */
 #undef COMMAND_LINE_SIZE

Re: Merge headerfiles for m68k and m68knommu to arch/m68k/include/asm

[Sam Ravnborg]

> 
> With the above construct we do the "right thing" also for
> headers exported to userspace.
> But actually none of the headers using the above are
> subject for export at the moment so we could use a
> CONFIG_ symbol for the same.

One thing worth adding is that this patch fixes:

    make ARCH=m68knommu headers_check

It did not work before - but with this patch is works
as expected.

	Sam

Re: Merge headerfiles for m68k and m68knommu to arch/m68k/include/asm

[Geert Uytterhoeven]

On Mon, 8 Dec 2008, Sam Ravnborg wrote:
> Following is a pseudo patch (a script + a patch) that merges
> the include files for m68k and m68knommu in one place at:
> 
>     arch/m68k/include/asm
> 
> The script was written by Arnd and I added a few modifications.

Thanks! I'll take a closer look when I'll find some spare time...

> I have used the following include guard:
> 
> #ifdef __uClinux__
> #include "atomic_no.h"
> #else
> #include "atomic_mm.h"
> #endif
> 
> gcc -E -dM for the two compilers revealed that this was the
> only symbol that differed.

I think you can share a toolchain for m68k and m68knommu, at least for the
kernel (I used my plain m68k toolchain when experimenting with m68knommu for
Amiga).

> With the above construct we do the "right thing" also for
> headers exported to userspace.
> But actually none of the headers using the above are
> subject for export at the moment so we could use a
> CONFIG_ symbol for the same.

So I prefer to just check CONFIG_MMU.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Merge headerfiles for m68k and m68knommu to arch/m68k/include/asm

[Arnd Bergmann]

On Tuesday 09 December 2008, Geert Uytterhoeven wrote:
> > I have used the following include guard:
> > 
> > #ifdef __uClinux__
> > #include "atomic_no.h"
> > #else
> > #include "atomic_mm.h"
> > #endif
> > 
> > gcc -E -dM for the two compilers revealed that this was the
> > only symbol that differed.
> 
> I think you can share a toolchain for m68k and m68knommu, at least for the
> kernel (I used my plain m68k toolchain when experimenting with m68knommu for
> Amiga).
> 
> > With the above construct we do the "right thing" also for
> > headers exported to userspace.
> > But actually none of the headers using the above are
> > subject for export at the moment so we could use a
> > CONFIG_ symbol for the same.
> 
> So I prefer to just check CONFIG_MMU.

Some of them are, by means of include/asm-generic/Kbuild.asm, e.g.
unistd.h!

I'm not sure if it's entirely correct, but I think you can use

#ifdef __KERNEL__
# ifdef CONFIG_MMU
#  include "atomic_mm.h
# else
#  include "atomic_no.h
# endif
#else
# ifndef __uClinux__
#  include "atomic_mm.h
# else
#  include "atomic_no.h
# endif
#endif

	Arnd <><

Re: Merge headerfiles for m68k and m68knommu to arch/m68k/include/asm

[Sam Ravnborg]

On Tue, Dec 09, 2008 at 12:26:05AM +0100, Arnd Bergmann wrote:
> On Tuesday 09 December 2008, Geert Uytterhoeven wrote:
> > > I have used the following include guard:
> > > 
> > > #ifdef __uClinux__
> > > #include "atomic_no.h"
> > > #else
> > > #include "atomic_mm.h"
> > > #endif
> > > 
> > > gcc -E -dM for the two compilers revealed that this was the
> > > only symbol that differed.
> > 
> > I think you can share a toolchain for m68k and m68knommu, at least for the
> > kernel (I used my plain m68k toolchain when experimenting with m68knommu for
> > Amiga).
> > 
> > > With the above construct we do the "right thing" also for
> > > headers exported to userspace.
> > > But actually none of the headers using the above are
> > > subject for export at the moment so we could use a
> > > CONFIG_ symbol for the same.
> > 
> > So I prefer to just check CONFIG_MMU.
> 
> Some of them are, by means of include/asm-generic/Kbuild.asm, e.g.
> unistd.h!
I was fooled by make headers_check showing no errros.
But it turns out that headers_check does not recognize
includes made with "".

So I will update the patch to include revevant *_{no,mm}.h files
in Kbuild.

> 
> I'm not sure if it's entirely correct, but I think you can use
> 
> #ifdef __KERNEL__
> # ifdef CONFIG_MMU
> #  include "atomic_mm.h
> # else
> #  include "atomic_no.h
> # endif
> #else
> # ifndef __uClinux__
> #  include "atomic_mm.h
> # else
> #  include "atomic_no.h
> # endif
> #endif

Can someone with a shared (m68k/m68knommu) please check if
__uClinux__ is only set in the m68knommu case.

Use:

    touch foo.h; gcc -E -dM

to see what is defined by the compiler.
You will also need to specify if this is for m68k or m68knommu.

Thanks,
	Sam

Re: Merge headerfiles for m68k and m68knommu to arch/m68k/include/asm

[Geert Uytterhoeven]

On Tue, 9 Dec 2008, Sam Ravnborg wrote:
> On Tue, Dec 09, 2008 at 12:26:05AM +0100, Arnd Bergmann wrote:
> > On Tuesday 09 December 2008, Geert Uytterhoeven wrote:
> > > > I have used the following include guard:
> > > > 
> > > > #ifdef __uClinux__
> > > > #include "atomic_no.h"
> > > > #else
> > > > #include "atomic_mm.h"
> > > > #endif
> > > > 
> > > > gcc -E -dM for the two compilers revealed that this was the
> > > > only symbol that differed.
> > > 
> > > I think you can share a toolchain for m68k and m68knommu, at least for the
> > > kernel (I used my plain m68k toolchain when experimenting with m68knommu for
> > > Amiga).
> > > 
> > > > With the above construct we do the "right thing" also for
> > > > headers exported to userspace.
> > > > But actually none of the headers using the above are
> > > > subject for export at the moment so we could use a
> > > > CONFIG_ symbol for the same.
> > > 
> > > So I prefer to just check CONFIG_MMU.
> > 
> > Some of them are, by means of include/asm-generic/Kbuild.asm, e.g.
> > unistd.h!

Interesting, I'd expect unistd.h to be the same!

Ah, it's the restart_syscall:

--- include/asm-m68k/unistd.h	2008-10-18 10:34:15.000000000 +0200
+++ arch/m68knommu/include/asm/unistd.h	2008-10-12 14:08:01.000000000 +0200
@@ -5,6 +5,7 @@
  * This file contains the system call numbers.
  */
 
+#define __NR_restart_syscall      0
 #define __NR_exit		  1
 #define __NR_fork		  2
 #define __NR_read		  3
@@ -359,9 +360,6 @@
 #define __ARCH_WANT_SYS_SIGPROCMASK
 #define __ARCH_WANT_SYS_RT_SIGACTION
 
-/* whitelist for checksyscalls */
-#define __IGNORE_restart_syscall
-
 /*
  * "Conditional" syscalls
  *

Sorry, I don't know about syscall restart handling, and why it differs. Anyone
who can enlighten me?

> I was fooled by make headers_check showing no errros.
> But it turns out that headers_check does not recognize
> includes made with "".
> 
> So I will update the patch to include revevant *_{no,mm}.h files
> in Kbuild.
> 
> > 
> > I'm not sure if it's entirely correct, but I think you can use
> > 
> > #ifdef __KERNEL__
> > # ifdef CONFIG_MMU
> > #  include "atomic_mm.h
> > # else
> > #  include "atomic_no.h
> > # endif
> > #else
> > # ifndef __uClinux__
> > #  include "atomic_mm.h
> > # else
> > #  include "atomic_no.h
> > # endif
> > #endif
> 
> Can someone with a shared (m68k/m68knommu) please check if
> __uClinux__ is only set in the m68knommu case.
                 ^^^^
		 always and only
> 
> Use:
> 
>     touch foo.h; gcc -E -dM
> 
> to see what is defined by the compiler.
> You will also need to specify if this is for m68k or m68knommu.

Still, I don't see why the compiler needs to be aware of being configured for
m68k or m68knommu, so IMHO this is a very fragile test...

What are the other exported headers that differ?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Merge headerfiles for m68k and m68knommu to arch/m68k/include/asm

[Andreas Schwab]

Geert Uytterhoeven <geert@linux-m68k.org> writes:

> Ah, it's the restart_syscall:
>
> --- include/asm-m68k/unistd.h	2008-10-18 10:34:15.000000000 +0200
> +++ arch/m68knommu/include/asm/unistd.h	2008-10-12 14:08:01.000000000 +0200
> @@ -5,6 +5,7 @@
>   * This file contains the system call numbers.
>   */
>  
> +#define __NR_restart_syscall      0
>  #define __NR_exit		  1
>  #define __NR_fork		  2
>  #define __NR_read		  3
> @@ -359,9 +360,6 @@
>  #define __ARCH_WANT_SYS_SIGPROCMASK
>  #define __ARCH_WANT_SYS_RT_SIGACTION
>  
> -/* whitelist for checksyscalls */
> -#define __IGNORE_restart_syscall
> -
>  /*
>   * "Conditional" syscalls
>   *
>
> Sorry, I don't know about syscall restart handling, and why it differs. Anyone
> who can enlighten me?

The syscall restart handling is not yet implemented on m68k(nommu), so
there is no real difference.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Merge headerfiles for m68k and m68knommu to arch/m68k/include/asm

[Arnd Bergmann]

On Tuesday 09 December 2008, Geert Uytterhoeven wrote:
> What are the other exported headers that differ?

byteorder.h, param.h, ptrace.h, setup.h, sigcontext.h, siginfo.h, signal.h
and unistd.h.

	Arnd <><

Re: [uClinux-dev] Re: Merge headerfiles for m68k and m68knommu to arch/m68k/include/asm

[Allon Stern]

On Dec 8, 2008, at 6:01 PM, Geert Uytterhoeven wrote:
>
> I think you can share a toolchain for m68k and m68knommu, at least  
> for the
> kernel (I used my plain m68k toolchain when experimenting with  
> m68knommu for
> Amiga).

The coldfire (m68knommu) doesn't have some instructions; this caused  
us some grief in the assembly code exported from m68k for byte order  
in user-space.

-
allon

Re: [uClinux-dev] Re: Merge headerfiles for m68k and m68knommu to arch/m68k/include/asm

[Geert Uytterhoeven]

On Tue, 9 Dec 2008, Allon Stern wrote:
> On Dec 8, 2008, at 6:01 PM, Geert Uytterhoeven wrote:
> > I think you can share a toolchain for m68k and m68knommu, at least for the
> > kernel (I used my plain m68k toolchain when experimenting with m68knommu for
> > Amiga).
> 
> The coldfire (m68knommu) doesn't have some instructions; this caused us some
> grief in the assembly code exported from m68k for byte order in user-space.

Sure, but that one is nicely protected by "#if defined (__mcfisaaplus__) ||
defined (__mcfisac__)", right?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Merge headerfiles for m68k and m68knommu to arch/m68k/include/asm

[Sam Ravnborg]

On Tue, Dec 09, 2008 at 12:02:46PM +0100, Arnd Bergmann wrote:
> On Tuesday 09 December 2008, Geert Uytterhoeven wrote:
> > What are the other exported headers that differ?
> 
> byteorder.h, param.h, ptrace.h, setup.h, sigcontext.h, siginfo.h, signal.h
> and unistd.h.

And diffing these files for the most part it looked like
a simple job for someone with some basic m68k/m68knommu knowledge
to unify these.

That would be a natural next step when the headers
are unified. I do not see it as a prerequisite for the
merge of the header files.

	Sam

Re: Merge headerfiles for m68k and m68knommu to arch/m68k/include/asm

[Geert Uytterhoeven]

On Tue, 9 Dec 2008, Sam Ravnborg wrote:
> On Tue, Dec 09, 2008 at 12:26:05AM +0100, Arnd Bergmann wrote:
> > On Tuesday 09 December 2008, Geert Uytterhoeven wrote:
> > > > I have used the following include guard:
> > > > 
> > > > #ifdef __uClinux__
> > > > #include "atomic_no.h"
> > > > #else
> > > > #include "atomic_mm.h"
> > > > #endif
> > > > 
> > > > gcc -E -dM for the two compilers revealed that this was the
> > > > only symbol that differed.
> > > 
> > > I think you can share a toolchain for m68k and m68knommu, at least for the
> > > kernel (I used my plain m68k toolchain when experimenting with m68knommu for
> > > Amiga).
> > > 
> > > > With the above construct we do the "right thing" also for
> > > > headers exported to userspace.
> > > > But actually none of the headers using the above are
> > > > subject for export at the moment so we could use a
> > > > CONFIG_ symbol for the same.
> > > 
> > > So I prefer to just check CONFIG_MMU.
> > 
> > Some of them are, by means of include/asm-generic/Kbuild.asm, e.g.
> > unistd.h!
> I was fooled by make headers_check showing no errros.
> But it turns out that headers_check does not recognize
> includes made with "".
> 
> So I will update the patch to include revevant *_{no,mm}.h files
> in Kbuild.
> 
> > 
> > I'm not sure if it's entirely correct, but I think you can use
> > 
> > #ifdef __KERNEL__
> > # ifdef CONFIG_MMU
> > #  include "atomic_mm.h
> > # else
> > #  include "atomic_no.h
> > # endif
> > #else
> > # ifndef __uClinux__
> > #  include "atomic_mm.h
> > # else
> > #  include "atomic_no.h
> > # endif
> > #endif
> 
> Can someone with a shared (m68k/m68knommu) please check if
> __uClinux__ is only set in the m68knommu case.
> 
> Use:
> 
>     touch foo.h; gcc -E -dM
> 
> to see what is defined by the compiler.
> You will also need to specify if this is for m68k or m68knommu.

Any comments from the m68knommu toolchain people?

None of my m68k-linux compilers set __uClinux__, as expected.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Merge headerfiles for m68k and m68knommu to arch/m68k/include/asm

[Andreas Schwab]

Geert Uytterhoeven <geert@linux-m68k.org> writes:

> None of my m68k-linux compilers set __uClinux__, as expected.

IIUC, userspace ABI is supposed to be completely identical.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [uClinux-dev] Re: Merge headerfiles for m68k and m68knommu to arch/m68k/include/asm

[Allon Stern]

On Dec 9, 2008, at 12:39 PM, Geert Uytterhoeven wrote:
> Sure, but that one is nicely protected by "#if defined  
> (__mcfisaaplus__) ||
> defined (__mcfisac__)", right?

Well, that was the patch we had to apply.
It wasn't in the baseline kernel.org kernel.
-
allon

Re: Merge headerfiles for m68k and m68knommu to arch/m68k/include/asm

[Arnd Bergmann]

On Thursday 11 December 2008, Andreas Schwab wrote:
> Geert Uytterhoeven <geert@linux-m68k.org> writes:
> 
> > None of my m68k-linux compilers set __uClinux__, as expected.
> 
> IIUC, userspace ABI is supposed to be completely identical.

The header files are currently different for the definitions of
__arch__swab32, EXEC_PAGESIZE, struct sigcontext, struct siginfo,
struct pt_regs (coldfire only) and COMMAND_LINE_SIZE.

I don't expect the last two to cause any trouble, but the others
are likely to.

__arch_swab32 should be protected with __mcfisaaplus__ (as it
already is on m68knommu). 

pt_regs on m68knommu is already screwed by itself, because it
depends on the CONFIG_COLDFIRE symbol. I don't think that it's
possible to build a gdb for coldfire with the current headers,
because CONFIG_* symbols are not visible in user space.

The signal handling ABI is currently broken on m68knommu:

commit 19dbaf6f6 "m68knommu: save reg a5 on context change",
changes the layout of struct sigcontext in an incompatible
way from older m68knommu and all m68k versions.

Prior to that, Linux-2.5.64 changed m68knommu to use the generic
siginfo instead of the m68k compatible one, thereby removing
uid32 support from it. This breaks when you build a libc with
uid32 against the m68k headers.

	Arnd <><

Re: Merge headerfiles for m68k and m68knommu to arch/m68k/include/asm

[Geert Uytterhoeven]

On Thu, 11 Dec 2008, Geert Uytterhoeven wrote:
> On Tue, 9 Dec 2008, Sam Ravnborg wrote:
> > On Tue, Dec 09, 2008 at 12:26:05AM +0100, Arnd Bergmann wrote:
> > > On Tuesday 09 December 2008, Geert Uytterhoeven wrote:
> > > > > I have used the following include guard:
> > > > > 
> > > > > #ifdef __uClinux__
> > > > > #include "atomic_no.h"
> > > > > #else
> > > > > #include "atomic_mm.h"
> > > > > #endif
> > > > > 
> > > > > gcc -E -dM for the two compilers revealed that this was the
> > > > > only symbol that differed.
> > > > 
> > > > I think you can share a toolchain for m68k and m68knommu, at least for the
> > > > kernel (I used my plain m68k toolchain when experimenting with m68knommu for
> > > > Amiga).
> > > > 
> > > > > With the above construct we do the "right thing" also for
> > > > > headers exported to userspace.
> > > > > But actually none of the headers using the above are
> > > > > subject for export at the moment so we could use a
> > > > > CONFIG_ symbol for the same.
> > > > 
> > > > So I prefer to just check CONFIG_MMU.
> > > 
> > > Some of them are, by means of include/asm-generic/Kbuild.asm, e.g.
> > > unistd.h!
> > I was fooled by make headers_check showing no errros.
> > But it turns out that headers_check does not recognize
> > includes made with "".
> > 
> > So I will update the patch to include revevant *_{no,mm}.h files
> > in Kbuild.
> > 
> > > I'm not sure if it's entirely correct, but I think you can use
> > > 
> > > #ifdef __KERNEL__
> > > # ifdef CONFIG_MMU
> > > #  include "atomic_mm.h
> > > # else
> > > #  include "atomic_no.h
> > > # endif
> > > #else
> > > # ifndef __uClinux__
> > > #  include "atomic_mm.h
> > > # else
> > > #  include "atomic_no.h
> > > # endif
> > > #endif
> > 
> > Can someone with a shared (m68k/m68knommu) please check if
> > __uClinux__ is only set in the m68knommu case.
> > 
> > Use:
> > 
> >     touch foo.h; gcc -E -dM
> > 
> > to see what is defined by the compiler.
> > You will also need to specify if this is for m68k or m68knommu.
> 
> Any comments from the m68knommu toolchain people?
> 
> None of my m68k-linux compilers set __uClinux__, as expected.

Can't we unifdef out in scripts/headers_install.pl based on CONFIG_MMU?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [uClinux-dev] Re: Merge headerfiles for m68k and m68knommu to arch/m68k/include/asm

[Greg Ungerer]

Allon Stern wrote:
> On Dec 9, 2008, at 12:39 PM, Geert Uytterhoeven wrote:
>> Sure, but that one is nicely protected by "#if defined 
>> (__mcfisaaplus__) ||
>> defined (__mcfisac__)", right?
> 
> Well, that was the patch we had to apply.
> It wasn't in the baseline kernel.org kernel.

What kernel.org version?
Its has been in for a little while.
In 2.6.28-rc8:

grep mcfisaaplus arch/m68knommu/include/asm/*

arch/m68knommu/include/asm/bitops.h:#if defined (__mcfisaaplus__) || 
defined (__mcfisac__)
arch/m68knommu/include/asm/byteorder.h:#if defined (__mcfisaaplus__) || 
defined (__mcfisac__)


Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear, a McAfee Company                  PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com

Re: Merge headerfiles for m68k and m68knommu to arch/m68k/include/asm

[Greg Ungerer]

Geert Uytterhoeven wrote:
> On Tue, 9 Dec 2008, Sam Ravnborg wrote:
>> On Tue, Dec 09, 2008 at 12:26:05AM +0100, Arnd Bergmann wrote:
>>> On Tuesday 09 December 2008, Geert Uytterhoeven wrote:
>>>>> I have used the following include guard:
>>>>>
>>>>> #ifdef __uClinux__
>>>>> #include "atomic_no.h"
>>>>> #else
>>>>> #include "atomic_mm.h"
>>>>> #endif
>>>>>
>>>>> gcc -E -dM for the two compilers revealed that this was the
>>>>> only symbol that differed.
>>>> I think you can share a toolchain for m68k and m68knommu, at least for the
>>>> kernel (I used my plain m68k toolchain when experimenting with m68knommu for
>>>> Amiga).
>>>>
>>>>> With the above construct we do the "right thing" also for
>>>>> headers exported to userspace.
>>>>> But actually none of the headers using the above are
>>>>> subject for export at the moment so we could use a
>>>>> CONFIG_ symbol for the same.
>>>> So I prefer to just check CONFIG_MMU.
>>> Some of them are, by means of include/asm-generic/Kbuild.asm, e.g.
>>> unistd.h!
>> I was fooled by make headers_check showing no errros.
>> But it turns out that headers_check does not recognize
>> includes made with "".
>>
>> So I will update the patch to include revevant *_{no,mm}.h files
>> in Kbuild.
>>
>>> I'm not sure if it's entirely correct, but I think you can use
>>>
>>> #ifdef __KERNEL__
>>> # ifdef CONFIG_MMU
>>> #  include "atomic_mm.h
>>> # else
>>> #  include "atomic_no.h
>>> # endif
>>> #else
>>> # ifndef __uClinux__
>>> #  include "atomic_mm.h
>>> # else
>>> #  include "atomic_no.h
>>> # endif
>>> #endif
>> Can someone with a shared (m68k/m68knommu) please check if
>> __uClinux__ is only set in the m68knommu case.
>>
>> Use:
>>
>>     touch foo.h; gcc -E -dM
>>
>> to see what is defined by the compiler.
>> You will also need to specify if this is for m68k or m68knommu.
> 
> Any comments from the m68knommu toolchain people?
 >
> None of my m68k-linux compilers set __uClinux__, as expected.

A m68k-uclinux- gcc will. From a gcc-4.2.4

   m68k-uclinux-gcc -E -dM /tmp/foo.h | grep -i linux

   #define __linux 1
   #define __linux__ 1
   #define __uClinux__ 1
   #define __gnu_linux__ 1
   #define linux 1

(I think that is one of the very few differences of m68k-linux
over m68k-uclinux...)

I would rather just have a m68k-linux myself, and not have a
separate m68k-uclinux toolchain.

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear, a McAfee Company                  PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com

Re: Merge headerfiles for m68k and m68knommu to arch/m68k/include/asm

[Arnd Bergmann]

On Thursday 11 December 2008, Geert Uytterhoeven wrote:
> 
> > None of my m68k-linux compilers set __uClinux__, as expected.
> 
> Can't we unifdef out in scripts/headers_install.pl based on CONFIG_MMU?

That should work, but I'm not convinced that it is what you want.
If you want binaries to be used interchangably between the two,
you really need to fix the signal handling and pt_regs on m68knommu,
and someone should try to work out what EXEC_PAGESIZE and COMMAND_LINE_SIZE
should really be defined to.

	Arnd <><

Re: Merge headerfiles for m68k and m68knommu to arch/m68k/include/asm

[Sam Ravnborg]

On Tue, Dec 09, 2008 at 12:26:05AM +0100, Arnd Bergmann wrote:
> On Tuesday 09 December 2008, Geert Uytterhoeven wrote:
> > > I have used the following include guard:
> > > 
> > > #ifdef __uClinux__
> > > #include "atomic_no.h"
> > > #else
> > > #include "atomic_mm.h"
> > > #endif
> > > 
> > > gcc -E -dM for the two compilers revealed that this was the
> > > only symbol that differed.
> > 
> > I think you can share a toolchain for m68k and m68knommu, at least for the
> > kernel (I used my plain m68k toolchain when experimenting with m68knommu for
> > Amiga).
> > 
> > > With the above construct we do the "right thing" also for
> > > headers exported to userspace.
> > > But actually none of the headers using the above are
> > > subject for export at the moment so we could use a
> > > CONFIG_ symbol for the same.
> > 
> > So I prefer to just check CONFIG_MMU.
> 
> Some of them are, by means of include/asm-generic/Kbuild.asm, e.g.
> unistd.h!
> 
> I'm not sure if it's entirely correct, but I think you can use
> 
> #ifdef __KERNEL__
> # ifdef CONFIG_MMU
> #  include "atomic_mm.h
> # else
> #  include "atomic_no.h
> # endif
> #else
> # ifndef __uClinux__
> #  include "atomic_mm.h
> # else
> #  include "atomic_no.h
> # endif
> #endif

I kept the original way of doing it since all reports said that
__uClinux__ is set by the m68knommu toolchain.
Using only this symbol makes it simpler what happens.

	Sam

Re: Merge headerfiles for m68k and m68knommu to arch/m68k/include/asm

[Sam Ravnborg]

> >>
> >>>I'm not sure if it's entirely correct, but I think you can use
> >>>
> >>>#ifdef __KERNEL__
> >>># ifdef CONFIG_MMU
> >>>#  include "atomic_mm.h
> >>># else
> >>>#  include "atomic_no.h
> >>># endif
> >>>#else
> >>># ifndef __uClinux__
> >>>#  include "atomic_mm.h
> >>># else
> >>>#  include "atomic_no.h
> >>># endif
> >>>#endif
> >>Can someone with a shared (m68k/m68knommu) please check if
> >>__uClinux__ is only set in the m68knommu case.
> >>
> >>Use:
> >>
> >>    touch foo.h; gcc -E -dM
> >>
> >>to see what is defined by the compiler.
> >>You will also need to specify if this is for m68k or m68knommu.
> >
> >Any comments from the m68knommu toolchain people?
> >
> >None of my m68k-linux compilers set __uClinux__, as expected.
> 
> A m68k-uclinux- gcc will. From a gcc-4.2.4
> 
>   m68k-uclinux-gcc -E -dM /tmp/foo.h | grep -i linux
> 
>   #define __linux 1
>   #define __linux__ 1
>   #define __uClinux__ 1
>   #define __gnu_linux__ 1
>   #define linux 1
> 
> (I think that is one of the very few differences of m68k-linux
> over m68k-uclinux...)
> 
> I would rather just have a m68k-linux myself, and not have a
> separate m68k-uclinux toolchain.

A precondition for this is I expect a unified ABI for m68k and m68knommu.
With the merged headers it is now much more obvious where the ABI differs,
so fixing the ABI differences now got one step easier.

	Sam

Re: Merge headerfiles for m68k and m68knommu to arch/m68k/include/asm

[Sam Ravnborg]

On Mon, Dec 08, 2008 at 09:58:14PM +0100, Sam Ravnborg wrote:
> [this mail is cross posted to uclinux mailing list which is subscriber only]
> 
> Following is a pseudo patch (a script + a patch) that merges
> the include files for m68k and m68knommu in one place at:

I fixed the missing files so we now export
a proper set of files to userspace (checked with a local fix
to scripts/headers_check.pl).

I will followup with a patch generated by git.
So to apply it you must use git am.

Note: The patch simple move files around and create a few new
files so even if you have updated a few files since I created
the patch git will do the right-thing.

This patch unify the header files and as this thread has shown
there are potential for additional unification.
I see this patch as a natural first step and then we can later
address all the obvious unification tasks.

Please apply.

	Sam

Re: [PATCH] m68k,m68knommu: merge header files

[Geert Uytterhoeven]

On Sat, 13 Dec 2008, Sam Ravnborg wrote:
> >From 5a8b9717a399679c4753e596ea864b02a1197025 Mon Sep 17 00:00:00 2001
> From: Sam Ravnborg <sam@ravnborg.org>
> Date: Sat, 13 Dec 2008 21:23:08 +0100
> Subject: [PATCH] m68k,m68knommu: merge header files
> 
> Merge header files for m68k and m68knommu to the single location:
> 
>     arch/m68k/include/asm
> 
> The majority of this patch was the result of the
> script that is included in the changelog below.
> 
> The script was originally written by Arnd Bergman and
                                            ^^^^^^^
					    Bergmann
> exten by me to cover a few more files.
  ^^^^^
  extended

> When the header files differed the script uses the following:
> 
> The original m68k file is named <file>_mm.h  [mm for memory manager]
> The m68knommu file is named <file>_no.h [no for no memory manager]
> 
> The files uses the following include guard:
> 
> This include gaurd works as the m68knommu toolchain set
               ^^^^^
	       guard
> the __uClinux__ symbol - so this should work in userspace too.
> 
> Merging the header files for m68k and m68knommu exposes the
> (unexpected?) ABI differences thus it is easier to actually
> identify these and thus to fix them.
> 
> The commit has been build tested with both a m68k and
> a m68knommu toolchain - with success.
> 
> The commit has also been tested with "make headers_check"
> and this patch fixes make headers_check for m68knommu.
> 
> The script used:
> TARGET=arch/m68k/include/asm
> SOURCE=arch/m68knommu/include/asm
> 
> INCLUDE="cachectl.h errno.h fcntl.h hwtest.h ioctls.h ipcbuf.h \
> linkage.h math-emu.h md.h mman.h movs.h msgbuf.h openprom.h \
> oplib.h poll.h posix_types.h resource.h rtc.h sembuf.h shmbuf.h \
> shm.h shmparam.h socket.h sockios.h spinlock.h statfs.h stat.h \
> termbits.h termios.h tlb.h types.h user.h"
> 
> EQUAL="auxvec.h cputime.h device.h emergency-restart.h futex.h \
> ioctl.h irq_regs.h kdebug.h local.h mutex.h percpu.h \
> sections.h topology.h"
> 
> NOMUUFILES="anchor.h bootstd.h coldfire.h commproc.h dbg.h \
  ^^^^^^^^^^
  NOMMUFILES (as the same typo is present in the other parts of the script
              it still worked ;-)

> elia.h flat.h m5206sim.h m520xsim.h m523xsim.h m5249sim.h \
> m5272sim.h m527xsim.h m528xsim.h m5307sim.h m532xsim.h \
> m5407sim.h m68360_enet.h m68360.h m68360_pram.h m68360_quicc.h \
> m68360_regs.h MC68328.h MC68332.h MC68EZ328.h MC68VZ328.h \
> mcfcache.h mcfdma.h mcfmbus.h mcfne.h mcfpci.h mcfpit.h \
> mcfsim.h mcfsmc.h mcftimer.h mcfuart.h mcfwdebug.h \
> nettel.h quicc_simple.h smp.h"
> 
> FILES="atomic.h bitops.h bootinfo.h bug.h bugs.h byteorder.h cache.h \
> cacheflush.h checksum.h current.h delay.h div64.h \
> dma-mapping.h dma.h elf.h entry.h fb.h fpu.h hardirq.h hw_irq.h io.h \
> irq.h kmap_types.h machdep.h mc146818rtc.h mmu.h mmu_context.h \
> module.h page.h page_offset.h param.h pci.h pgalloc.h \
> pgtable.h processor.h ptrace.h scatterlist.h segment.h \
> setup.h sigcontext.h siginfo.h signal.h string.h system.h \
> thread_info.h timex.h tlbflush.h traps.h uaccess.h ucontext.h \
> unaligned.h unistd.h"
> 
> mergefile() {
> 	BASE=${1%.h}
> 	git mv ${SOURCE}/$1 ${TARGET}/${BASE}_no.h
> 	git mv ${TARGET}/$1 ${TARGET}/${BASE}_mm.h
> 
> cat << EOF > ${TARGET}/$1
> EOF
> 
> 	git add ${TARGET}/$1
> }
> 
> set -e
> 
> mkdir -p ${TARGET}
> 
> git mv include/asm-m68k/* ${TARGET}
> rmdir include/asm-m68k
> 
> git rm ${SOURCE}/Kbuild
> for F in $INCLUDE $EQUAL; do
> 	git rm ${SOURCE}/$F
> done
> 
> for F in $NOMUUFILES; do
> 	git mv ${SOURCE}/$F ${TARGET}/$F
> done
> 
> for F in $FILES ; do
> 	mergefile $F
> done
> 
> rmdir arch/m68knommu/include/asm
> rmdir arch/m68knommu/include
> 
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Greg Ungerer <gerg@uclinux.org>
> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>

m68k-bits are
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>

Thanks a lot, Arnd, Sam!

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [PATCH] m68k,m68knommu: merge header files

[Geert Uytterhoeven]

On Fri, 16 Jan 2009, Greg Ungerer wrote:
> Sam Ravnborg wrote:
> > > From 5a8b9717a399679c4753e596ea864b02a1197025 Mon Sep 17 00:00:00 2001
> > From: Sam Ravnborg <sam@ravnborg.org>
> > Date: Sat, 13 Dec 2008 21:23:08 +0100
> > Subject: [PATCH] m68k,m68knommu: merge header files
> > 
> > Merge header files for m68k and m68knommu to the single location:
> > 
> >     arch/m68k/include/asm
> > 
> > The majority of this patch was the result of the
> > script that is included in the changelog below.
> > 
> > The script was originally written by Arnd Bergman and
> > exten by me to cover a few more files.
> > 
> > When the header files differed the script uses the following:
> > 
> > The original m68k file is named <file>_mm.h  [mm for memory manager]
> > The m68knommu file is named <file>_no.h [no for no memory manager]
> > 
> > The files uses the following include guard:
> > 
> > This include gaurd works as the m68knommu toolchain set
> > the __uClinux__ symbol - so this should work in userspace too.
> > 
> > Merging the header files for m68k and m68knommu exposes the
> > (unexpected?) ABI differences thus it is easier to actually
> > identify these and thus to fix them.
> > 
> > The commit has been build tested with both a m68k and
> > a m68knommu toolchain - with success.
> > 
> > The commit has also been tested with "make headers_check"
> > and this patch fixes make headers_check for m68knommu.
> > 
> > The script used:
> > TARGET=arch/m68k/include/asm
> > SOURCE=arch/m68knommu/include/asm
> > 
> > INCLUDE="cachectl.h errno.h fcntl.h hwtest.h ioctls.h ipcbuf.h \
> > linkage.h math-emu.h md.h mman.h movs.h msgbuf.h openprom.h \
> > oplib.h poll.h posix_types.h resource.h rtc.h sembuf.h shmbuf.h \
> > shm.h shmparam.h socket.h sockios.h spinlock.h statfs.h stat.h \
> > termbits.h termios.h tlb.h types.h user.h"
> > 
> > EQUAL="auxvec.h cputime.h device.h emergency-restart.h futex.h \
> > ioctl.h irq_regs.h kdebug.h local.h mutex.h percpu.h \
> > sections.h topology.h"
> > 
> > NOMUUFILES="anchor.h bootstd.h coldfire.h commproc.h dbg.h \
> > elia.h flat.h m5206sim.h m520xsim.h m523xsim.h m5249sim.h \
> > m5272sim.h m527xsim.h m528xsim.h m5307sim.h m532xsim.h \
> > m5407sim.h m68360_enet.h m68360.h m68360_pram.h m68360_quicc.h \
> > m68360_regs.h MC68328.h MC68332.h MC68EZ328.h MC68VZ328.h \
> > mcfcache.h mcfdma.h mcfmbus.h mcfne.h mcfpci.h mcfpit.h \
> > mcfsim.h mcfsmc.h mcftimer.h mcfuart.h mcfwdebug.h \
> > nettel.h quicc_simple.h smp.h"
> > 
> > FILES="atomic.h bitops.h bootinfo.h bug.h bugs.h byteorder.h cache.h \
> > cacheflush.h checksum.h current.h delay.h div64.h \
> > dma-mapping.h dma.h elf.h entry.h fb.h fpu.h hardirq.h hw_irq.h io.h \
> > irq.h kmap_types.h machdep.h mc146818rtc.h mmu.h mmu_context.h \
> > module.h page.h page_offset.h param.h pci.h pgalloc.h \
> > pgtable.h processor.h ptrace.h scatterlist.h segment.h \
> > setup.h sigcontext.h siginfo.h signal.h string.h system.h \
> > thread_info.h timex.h tlbflush.h traps.h uaccess.h ucontext.h \
> > unaligned.h unistd.h"
> > 
> > mergefile() {
> > 	BASE=${1%.h}
> > 	git mv ${SOURCE}/$1 ${TARGET}/${BASE}_no.h
> > 	git mv ${TARGET}/$1 ${TARGET}/${BASE}_mm.h
> > 
> > cat << EOF > ${TARGET}/$1
> > EOF
> > 
> > 	git add ${TARGET}/$1
> > }
> > 
> > set -e
> > 
> > mkdir -p ${TARGET}
> > 
> > git mv include/asm-m68k/* ${TARGET}
> > rmdir include/asm-m68k
> > 
> > git rm ${SOURCE}/Kbuild
> > for F in $INCLUDE $EQUAL; do
> > 	git rm ${SOURCE}/$F
> > done
> > 
> > for F in $NOMUUFILES; do
> > 	git mv ${SOURCE}/$F ${TARGET}/$F
> > done
> > 
> > for F in $FILES ; do
> > 	mergefile $F
> > done
> > 
> > rmdir arch/m68knommu/include/asm
> > rmdir arch/m68knommu/include
> > 
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> > Cc: Greg Ungerer <gerg@uclinux.org>
> > Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
> 
> So I took this, applied, and have been running some tests
> on m68knommu.
> 
> I had to make 2 small changes to make it work on 2.6.29-rc1.
> I had to add swab.h into the list of FILES, and move the seting
> of hdr-arch for m68knommu in the top level Makefile to after the
> global hdr-arch setting (so all of about 3 lines later).
> 
> Otherwise it builds and runs fine for m68knommu in all
> cases I have tested so far.

Thanks!

> I have this applied as the only change at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git
> m68k-merge-includes

Huh, is this git repository really ca. 200 MiB?

> Sam Ravnborg (1):
>       m68k,m68knommu: merge header files
> 
> 
> More review, testing, comments welcome...
> Where to from here?

I'll pull from it and give it some m68k test builds.
After that, you can move it to for-next. If everything's well, it can go to
Linus.

Or should I amend and add my SoB and put it in m68k for-next?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [PATCH] m68k,m68knommu: merge header files

[Greg Ungerer]

Hi Geert,

Geert Uytterhoeven wrote:
> On Fri, 16 Jan 2009, Greg Ungerer wrote:
>> Sam Ravnborg wrote:
>>>> From 5a8b9717a399679c4753e596ea864b02a1197025 Mon Sep 17 00:00:00 2001
>>> From: Sam Ravnborg <sam@ravnborg.org>
>>> Date: Sat, 13 Dec 2008 21:23:08 +0100
>>> Subject: [PATCH] m68k,m68knommu: merge header files
>>>
>>> Merge header files for m68k and m68knommu to the single location:
>>>
>>>     arch/m68k/include/asm
>>>
>>> The majority of this patch was the result of the
>>> script that is included in the changelog below.
>>>
>>> The script was originally written by Arnd Bergman and
>>> exten by me to cover a few more files.
>>>
>>> When the header files differed the script uses the following:
>>>
>>> The original m68k file is named <file>_mm.h  [mm for memory manager]
>>> The m68knommu file is named <file>_no.h [no for no memory manager]
>>>
>>> The files uses the following include guard:
>>>
>>> This include gaurd works as the m68knommu toolchain set
>>> the __uClinux__ symbol - so this should work in userspace too.
>>>
>>> Merging the header files for m68k and m68knommu exposes the
>>> (unexpected?) ABI differences thus it is easier to actually
>>> identify these and thus to fix them.
>>>
>>> The commit has been build tested with both a m68k and
>>> a m68knommu toolchain - with success.
>>>
>>> The commit has also been tested with "make headers_check"
>>> and this patch fixes make headers_check for m68knommu.
>>>
>>> The script used:
>>> TARGET=arch/m68k/include/asm
>>> SOURCE=arch/m68knommu/include/asm
>>>
>>> INCLUDE="cachectl.h errno.h fcntl.h hwtest.h ioctls.h ipcbuf.h \
>>> linkage.h math-emu.h md.h mman.h movs.h msgbuf.h openprom.h \
>>> oplib.h poll.h posix_types.h resource.h rtc.h sembuf.h shmbuf.h \
>>> shm.h shmparam.h socket.h sockios.h spinlock.h statfs.h stat.h \
>>> termbits.h termios.h tlb.h types.h user.h"
>>>
>>> EQUAL="auxvec.h cputime.h device.h emergency-restart.h futex.h \
>>> ioctl.h irq_regs.h kdebug.h local.h mutex.h percpu.h \
>>> sections.h topology.h"
>>>
>>> NOMUUFILES="anchor.h bootstd.h coldfire.h commproc.h dbg.h \
>>> elia.h flat.h m5206sim.h m520xsim.h m523xsim.h m5249sim.h \
>>> m5272sim.h m527xsim.h m528xsim.h m5307sim.h m532xsim.h \
>>> m5407sim.h m68360_enet.h m68360.h m68360_pram.h m68360_quicc.h \
>>> m68360_regs.h MC68328.h MC68332.h MC68EZ328.h MC68VZ328.h \
>>> mcfcache.h mcfdma.h mcfmbus.h mcfne.h mcfpci.h mcfpit.h \
>>> mcfsim.h mcfsmc.h mcftimer.h mcfuart.h mcfwdebug.h \
>>> nettel.h quicc_simple.h smp.h"
>>>
>>> FILES="atomic.h bitops.h bootinfo.h bug.h bugs.h byteorder.h cache.h \
>>> cacheflush.h checksum.h current.h delay.h div64.h \
>>> dma-mapping.h dma.h elf.h entry.h fb.h fpu.h hardirq.h hw_irq.h io.h \
>>> irq.h kmap_types.h machdep.h mc146818rtc.h mmu.h mmu_context.h \
>>> module.h page.h page_offset.h param.h pci.h pgalloc.h \
>>> pgtable.h processor.h ptrace.h scatterlist.h segment.h \
>>> setup.h sigcontext.h siginfo.h signal.h string.h system.h \
>>> thread_info.h timex.h tlbflush.h traps.h uaccess.h ucontext.h \
>>> unaligned.h unistd.h"
>>>
>>> mergefile() {
>>> 	BASE=${1%.h}
>>> 	git mv ${SOURCE}/$1 ${TARGET}/${BASE}_no.h
>>> 	git mv ${TARGET}/$1 ${TARGET}/${BASE}_mm.h
>>>
>>> cat << EOF > ${TARGET}/$1
>>> EOF
>>>
>>> 	git add ${TARGET}/$1
>>> }
>>>
>>> set -e
>>>
>>> mkdir -p ${TARGET}
>>>
>>> git mv include/asm-m68k/* ${TARGET}
>>> rmdir include/asm-m68k
>>>
>>> git rm ${SOURCE}/Kbuild
>>> for F in $INCLUDE $EQUAL; do
>>> 	git rm ${SOURCE}/$F
>>> done
>>>
>>> for F in $NOMUUFILES; do
>>> 	git mv ${SOURCE}/$F ${TARGET}/$F
>>> done
>>>
>>> for F in $FILES ; do
>>> 	mergefile $F
>>> done
>>>
>>> rmdir arch/m68knommu/include/asm
>>> rmdir arch/m68knommu/include
>>>
>>> Cc: Arnd Bergmann <arnd@arndb.de>
>>> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
>>> Cc: Greg Ungerer <gerg@uclinux.org>
>>> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
>> So I took this, applied, and have been running some tests
>> on m68knommu.
>>
>> I had to make 2 small changes to make it work on 2.6.29-rc1.
>> I had to add swab.h into the list of FILES, and move the seting
>> of hdr-arch for m68knommu in the top level Makefile to after the
>> global hdr-arch setting (so all of about 3 lines later).
>>
>> Otherwise it builds and runs fine for m68knommu in all
>> cases I have tested so far.
> 
> Thanks!
> 
>> I have this applied as the only change at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git
>> m68k-merge-includes
> 
> Huh, is this git repository really ca. 200 MiB?

Hmm, seems kinda large. Maybe I didn't pack it properly?


>> Sam Ravnborg (1):
>>       m68k,m68knommu: merge header files
>>
>>
>> More review, testing, comments welcome...
>> Where to from here?
> 
> I'll pull from it and give it some m68k test builds.
> After that, you can move it to for-next. If everything's well, it can go to
> Linus.

Sounds like a plan.


> Or should I amend and add my SoB and put it in m68k for-next?

I am happy to go either way.

Regards
Greg



> Gr{oetje,eeting}s,
> 
> 						Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> 							    -- Linus Torvalds
> 


-- 
------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear, a McAfee Company                  PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com

Re: [PATCH] m68k,m68knommu: merge header files

[Sam Ravnborg]

> >>
> >>More review, testing, comments welcome...
> >>Where to from here?
> >
> >I'll pull from it and give it some m68k test builds.
> >After that, you can move it to for-next. If everything's well, it can go to
> >Linus.
> 
> Sounds like a plan.
> 
> 
> >Or should I amend and add my SoB and put it in m68k for-next?
> 
> I am happy to go either way.

For my part I like this to reach mainline ASAP. So whatever suits the
two of you is fine with me.

	Sam

Re: [PATCH] m68k,m68knommu: merge header files

[Geert Uytterhoeven]

On Fri, 16 Jan 2009, Sam Ravnborg wrote:
> > >>More review, testing, comments welcome...
> > >>Where to from here?
> > >
> > >I'll pull from it and give it some m68k test builds.
> > >After that, you can move it to for-next. If everything's well, it can go to
> > >Linus.
> > 
> > Sounds like a plan.
> > 
> > 
> > >Or should I amend and add my SoB and put it in m68k for-next?
> > 
> > I am happy to go either way.
> 
> For my part I like this to reach mainline ASAP. So whatever suits the
> two of you is fine with me.

I pulled from Greg's tree, and built atari_defconfig, multi_defconfig,
sun3_defconfig. Atari_defconfig runs fine under ARAnyM.

As I'll be on a business trip to Japan next week, I probably won't be able to
do a proper follow-up. So Greg, can you put it on your for-next branch and
send it to Linus if everything goes well?

Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>

Thx!

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [PATCH] m68k,m68knommu: merge header files

[Greg Ungerer]

Hi Geert,

Geert Uytterhoeven wrote:
> On Fri, 16 Jan 2009, Sam Ravnborg wrote:
>>>>> More review, testing, comments welcome...
>>>>> Where to from here?
>>>> I'll pull from it and give it some m68k test builds.
>>>> After that, you can move it to for-next. If everything's well, it can go to
>>>> Linus.
>>> Sounds like a plan.
>>>
>>>
>>>> Or should I amend and add my SoB and put it in m68k for-next?
>>> I am happy to go either way.
>> For my part I like this to reach mainline ASAP. So whatever suits the
>> two of you is fine with me.
> 
> I pulled from Greg's tree, and built atari_defconfig, multi_defconfig,
> sun3_defconfig. Atari_defconfig runs fine under ARAnyM.
> 
> As I'll be on a business trip to Japan next week, I probably won't be able to
> do a proper follow-up. So Greg, can you put it on your for-next branch and
> send it to Linus if everything goes well?
> 
> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>

Yep, I can take care of that.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear, a McAfee Company                  PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com