Skip to contentSkip to conversation

merge of m68knommu and m68k arch branches?

PATCH Greg Ungerer 5 participants 20 messages Feb 18, 2011 – Mar 18, 2011 m68k architecture

lore
Share & tools
lore
#0 lore raw

Hi All,

I would like to put up for discussion a merge of the m68knommu and m68k arch branches.

Attached is a script and patch that does a kind of brute force simplistic merge of the directories and files. (Thanks to Stephen King <[email protected]> for the initial version of this script, and to Sam Ravnborg for the m68k includes merge script this was based on). Nothing outside of the arch/m68k and arch/m68knommu directories is touched, and in the end there is no more arch/m68knommu. To apply you simply run the script from the top of a current kernel git tree (I used 2.6.38-rc5 for testing) and then apply the patch.

This results in a tree that builds and runs on m68knommu targets that I tested, and at least builds with seemingly no change on m68k targets (I have not actually tested anything on a real m68k target). Configuring kernels results in the .config files containing the same option sets (though a few options appear in a different place/order).

Inside of the new arch/m68k is a little messy in the kernel and mm directories. There is plenty of scope for cleanup and merge on the files in here - but I want to leave that for follow up patches after this initial directory merge. As a data point, when we merged the m68k and m68knommu include files we had something like 70 or 80 duplicate but separate files, after some cleanups that is now down to
10. Ongoing cleanup will merge some of these remaining ones as well.

Thoughts?

Regards
Greg

------------------------------------------------------------------------

Greg Ungerer  --  Principal Engineer        EMAIL:     [email protected]
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close                             FAX:         +61 7 3217 5323
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com
arch/m68k/Kconfig +34 -391
diff -Naurp linux-2.6.x.half-merge/arch/m68k/Kconfig linux-2.6.x.full-merge/arch/m68k/Kconfig
@@ -1,13 +1,10 @@
 config M68K
 	bool
 	default y
-	select HAVE_AOUT
 	select HAVE_IDE
-	select GENERIC_ATOMIC64
-
-config MMU
-	bool
-	default y
+	select HAVE_AOUT if MMU
+	select GENERIC_ATOMIC64 if MMU
+	select HAVE_GENERIC_HARDIRQS if !MMU
 
 config RWSEM_GENERIC_SPINLOCK
 	bool
@@ -36,426 +33,70 @@ config TIME_LOW_RES
 	bool
 	default y
 
-config GENERIC_IOMAP
-	bool
-	default y
-
-config ARCH_MAY_HAVE_PC_FDC
-	bool
-	depends on BROKEN && (Q40 || SUN3X)
-	default y
-
 config NO_IOPORT
 	def_bool y
 
 config NO_DMA
-	def_bool SUN3
+	def_bool (MMU && SUN3) || (!MMU && !COLDFIRE)
+
+config ZONE_DMA
+	bool
+	default y
 
 config HZ
 	int
+	default 1000 if CLEOPATRA
 	default 100
 
-config ARCH_USES_GETTIMEOFFSET
-	def_bool y
-
 source "init/Kconfig"
 
 source "kernel/Kconfig.freezer"
 
-menu "Platform dependent setup"
-
-config EISA
-	bool
-	---help---
-	  The Extended Industry Standard Architecture (EISA) bus was
-	  developed as an open alternative to the IBM MicroChannel bus.
-
-	  The EISA bus provided some of the features of the IBM MicroChannel
-	  bus while maintaining backward compatibility with cards made for
-	  the older ISA bus.  The EISA bus saw limited use between 1988 and
-	  1995 when it was made obsolete by the PCI bus.
-
-	  Say Y here if you are building a kernel for an EISA-based machine.
-
-	  Otherwise, say N.
-
-config MCA
-	bool
-	help
-	  MicroChannel Architecture is found in some IBM PS/2 machines and
-	  laptops.  It is a bus system similar to PCI or ISA. See
-	  <file:Documentation/mca.txt> (and especially the web page given
-	  there) before attempting to build an MCA bus kernel.
-
-config PCMCIA
-	tristate
-	---help---
-	  Say Y here if you want to attach PCMCIA- or PC-cards to your Linux
-	  computer.  These are credit-card size devices such as network cards,
-	  modems or hard drives often used with laptops computers.  There are
-	  actually two varieties of these cards: the older 16 bit PCMCIA cards
-	  and the newer 32 bit CardBus cards.  If you want to use CardBus
-	  cards, you need to say Y here and also to "CardBus support" below.
-
-	  To use your PC-cards, you will need supporting software from David
-	  Hinds' pcmcia-cs package (see the file <file:Documentation/Changes>
-	  for location).  Please also read the PCMCIA-HOWTO, available from
-	  <http://www.tldp.org/docs.html#howto>.
-
-	  To compile this driver as modules, choose M here: the
-	  modules will be called pcmcia_core and ds.
-
-config AMIGA
-	bool "Amiga support"
-	select MMU_MOTOROLA if MMU
-	help
-	  This option enables support for the Amiga series of computers. If
-	  you plan to use this kernel on an Amiga, say Y here and browse the
-	  material available in <file:Documentation/m68k>; otherwise say N.
-
-config ATARI
-	bool "Atari support"
-	select MMU_MOTOROLA if MMU
-	help
-	  This option enables support for the 68000-based Atari series of
-	  computers (including the TT, Falcon and Medusa). If you plan to use
-	  this kernel on an Atari, say Y here and browse the material
-	  available in <file:Documentation/m68k>; otherwise say N.
-
-config MAC
-	bool "Macintosh support"
-	select MMU_MOTOROLA if MMU
-	help
-	  This option enables support for the Apple Macintosh series of
-	  computers (yes, there is experimental support now, at least for part
-	  of the series).
-
-	  Say N unless you're willing to code the remaining necessary support.
-	  ;)
-
-config NUBUS
-	bool
-	depends on MAC
-	default y
-
-config M68K_L2_CACHE
-	bool
-	depends on MAC
-	default y
-
-config APOLLO
-	bool "Apollo support"
-	select MMU_MOTOROLA if MMU
-	help
-	  Say Y here if you want to run Linux on an MC680x0-based Apollo
-	  Domain workstation such as the DN3500.
-
-config VME
-	bool "VME (Motorola and BVM) support"
-	select MMU_MOTOROLA if MMU
-	help
-	  Say Y here if you want to build a kernel for a 680x0 based VME
-	  board.  Boards currently supported include Motorola boards MVME147,
-	  MVME162, MVME166, MVME167, MVME172, and MVME177.  BVME4000 and
-	  BVME6000 boards from BVM Ltd are also supported.
-
-config MVME147
-	bool "MVME147 support"
-	depends on VME
-	help
-	  Say Y to include support for early Motorola VME boards.  This will
-	  build a kernel which can run on MVME147 single-board computers.  If
-	  you select this option you will have to select the appropriate
-	  drivers for SCSI, Ethernet and serial ports later on.
-
-config MVME16x
-	bool "MVME162, 166 and 167 support"
-	depends on VME
-	help
-	  Say Y to include support for Motorola VME boards.  This will build a
-	  kernel which can run on MVME162, MVME166, MVME167, MVME172, and
-	  MVME177 boards.  If you select this option you will have to select
-	  the appropriate drivers for SCSI, Ethernet and serial ports later
-	  on.
-
-config BVME6000
-	bool "BVME4000 and BVME6000 support"
-	depends on VME
-	help
-	  Say Y to include support for VME boards from BVM Ltd.  This will
-	  build a kernel which can run on BVME4000 and BVME6000 boards.  If
-	  you select this option you will have to select the appropriate
-	  drivers for SCSI, Ethernet and serial ports later on.
-
-config HP300
-	bool "HP9000/300 and HP9000/400 support"
-	select MMU_MOTOROLA if MMU
-	help
-	  This option enables support for the HP9000/300 and HP9000/400 series
-	  of workstations. Support for these machines is still somewhat
-	  experimental. If you plan to try to use the kernel on such a machine
-	  say Y here.
-	  Everybody else says N.
-
-config DIO
-	bool "DIO bus support"
-	depends on HP300
+config MMU
+	bool "MMU-based Paged Memory Management Support"
 	default y
 	help
-	  Say Y here to enable support for the "DIO" expansion bus used in
-	  HP300 machines. If you are using such a system you almost certainly
-	  want this.
-
-config SUN3X
-	bool "Sun3x support"
-	select MMU_MOTOROLA if MMU
-	select M68030
-	help
-	  This option enables support for the Sun 3x series of workstations.
-	  Be warned that this support is very experimental.
-	  Note that Sun 3x kernels are not compatible with Sun 3 hardware.
-	  General Linux information on the Sun 3x series (now discontinued)
-	  is at <http://www.angelfire.com/ca2/tech68k/sun3.html>.
-
-	  If you don't want to compile a kernel for a Sun 3x, say N.
-
-config Q40
-	bool "Q40/Q60 support"
-	select MMU_MOTOROLA if MMU
-	help
-	  The Q40 is a Motorola 68040-based successor to the Sinclair QL
-	  manufactured in Germany.  There is an official Q40 home page at
-	  <http://www.q40.de/>.  This option enables support for the Q40 and
-	  Q60. Select your CPU below.  For 68LC060 don't forget to enable FPU
-	  emulation.
-
-config SUN3
-	bool "Sun3 support"
-	depends on !MMU_MOTOROLA
-	select MMU_SUN3 if MMU
-	select M68020
-	help
-	  This option enables support for the Sun 3 series of workstations
-	  (3/50, 3/60, 3/1xx, 3/2xx systems). Enabling this option requires
-	  that all other hardware types must be disabled, as Sun 3 kernels
-	  are incompatible with all other m68k targets (including Sun 3x!).
-
-	  If you don't want to compile a kernel exclusively for a Sun 3, say N.
-
-comment "Processor type"
-
-config M68020
-	bool "68020 support"
-	help
-	  If you anticipate running this kernel on a computer with a MC68020
-	  processor, say Y. Otherwise, say N. Note that the 68020 requires a
-	  68851 MMU (Memory Management Unit) to run Linux/m68k, except on the
-	  Sun 3, which provides its own version.
-
-config M68030
-	bool "68030 support"
-	depends on !MMU_SUN3
-	help
-	  If you anticipate running this kernel on a computer with a MC68030
-	  processor, say Y. Otherwise, say N. Note that a MC68EC030 will not
-	  work, as it does not include an MMU (Memory Management Unit).
-
-config M68040
-	bool "68040 support"
-	depends on !MMU_SUN3
-	help
-	  If you anticipate running this kernel on a computer with a MC68LC040
-	  or MC68040 processor, say Y. Otherwise, say N. Note that an
-	  MC68EC040 will not work, as it does not include an MMU (Memory
-	  Management Unit).
-
-config M68060
-	bool "68060 support"
-	depends on !MMU_SUN3
-	help
-	  If you anticipate running this kernel on a computer with a MC68060
-	  processor, say Y. Otherwise, say N.
-
-config MMU_MOTOROLA
-	bool
-
-config MMU_SUN3
-	bool
-	depends on MMU && !MMU_MOTOROLA
-
-config M68KFPU_EMU
-	bool "Math emulation support (EXPERIMENTAL)"
-	depends on EXPERIMENTAL
-	help
-	  At some point in the future, this will cause floating-point math
-	  instructions to be emulated by the kernel on machines that lack a
-	  floating-point math coprocessor.  Thrill-seekers and chronically
-	  sleep-deprived psychotic hacker types can say Y now, everyone else
-	  should probably wait a while.
-
-config M68KFPU_EMU_EXTRAPREC
-	bool "Math emulation extra precision"
-	depends on M68KFPU_EMU
-	help
-	  The fpu uses normally a few bit more during calculations for
-	  correct rounding, the emulator can (often) do the same but this
-	  extra calculation can cost quite some time, so you can disable
-	  it here. The emulator will then "only" calculate with a 64 bit
-	  mantissa and round slightly incorrect, what is more than enough
-	  for normal usage.
-
-config M68KFPU_EMU_ONLY
-	bool "Math emulation only kernel"
-	depends on M68KFPU_EMU
-	help
-	  This option prevents any floating-point instructions from being
-	  compiled into the kernel, thereby the kernel doesn't save any
-	  floating point context anymore during task switches, so this
-	  kernel will only be usable on machines without a floating-point
-	  math coprocessor. This makes the kernel a bit faster as no tests
-	  needs to be executed whether a floating-point instruction in the
-	  kernel should be executed or not.
-
-config ADVANCED
-	bool "Advanced configuration options"
-	---help---
-	  This gives you access to some advanced options for the CPU. The
-	  defaults should be fine for most users, but these options may make
-	  it possible for you to improve performance somewhat if you know what
-	  you are doing.
-
-	  Note that the answer to this question won't directly affect the
-	  kernel: saying N will just cause the configurator to skip all
-	  the questions about these options.
-
-	  Most users should say N to this question.
-
-config RMW_INSNS
-	bool "Use read-modify-write instructions"
-	depends on ADVANCED
-	---help---
-	  This allows to use certain instructions that work with indivisible
-	  read-modify-write bus cycles. While this is faster than the
-	  workaround of disabling interrupts, it can conflict with DMA
-	  ( = direct memory access) on many Amiga systems, and it is also said
-	  to destabilize other machines. It is very likely that this will
-	  cause serious problems on any Amiga or Atari Medusa if set. The only
-	  configuration where it should work are 68030-based Ataris, where it
-	  apparently improves performance. But you've been warned! Unless you
-	  really know what you are doing, say N. Try Y only if you're quite
-	  adventurous.
-
-config SINGLE_MEMORY_CHUNK
-	bool "Use one physical chunk of memory only" if ADVANCED && !SUN3
-	default y if SUN3
-	select NEED_MULTIPLE_NODES
-	help
-	  Ignore all but the first contiguous chunk of physical memory for VM
-	  purposes.  This will save a few bytes kernel size and may speed up
-	  some operations.  Say N if not sure.
-
-config 060_WRITETHROUGH
-	bool "Use write-through caching for 68060 supervisor accesses"
-	depends on ADVANCED && M68060
-	---help---
-	  The 68060 generally uses copyback caching of recently accessed data.
-	  Copyback caching means that memory writes will be held in an on-chip
-	  cache and only written back to memory some time later.  Saying Y
-	  here will force supervisor (kernel) accesses to use writethrough
-	  caching.  Writethrough caching means that data is written to memory
-	  straight away, so that cache and memory data always agree.
-	  Writethrough caching is less efficient, but is needed for some
-	  drivers on 68060 based systems where the 68060 bus snooping signal
-	  is hardwired on.  The 53c710 SCSI driver is known to suffer from
-	  this problem.
+	  Select if you want MMU-based virtualised addressing space
+	  support by paged memory management. If unsure, say 'Y'.
 
-config ARCH_DISCONTIGMEM_ENABLE
-	def_bool !SINGLE_MEMORY_CHUNK
+menu "Platform dependent setup"
 
-config NODES_SHIFT
-	int
-	default "3"
-	depends on !SINGLE_MEMORY_CHUNK
+if MMU
+source arch/m68k/Kconfig.mmu
+endif
+if !MMU
+source arch/m68k/Kconfig.nommu
+endif
 
 source "mm/Kconfig"
 
 endmenu
 
-menu "General setup"
+menu "Executable file formats"
 
 source "fs/Kconfig.binfmt"
 
-config ZORRO
-	bool "Amiga Zorro (AutoConfig) bus support"
-	depends on AMIGA
-	help
-	  This enables support for the Zorro bus in the Amiga. If you have
-	  expansion cards in your Amiga that conform to the Amiga
-	  AutoConfig(tm) specification, say Y, otherwise N. Note that even
-	  expansion cards that do not fit in the Zorro slots but fit in e.g.
-	  the CPU slot may fall in this category, so you have to say Y to let
-	  Linux use these.
-
-config AMIGA_PCMCIA
-	bool "Amiga 1200/600 PCMCIA support (EXPERIMENTAL)"
-	depends on AMIGA && EXPERIMENTAL
-	help
-	  Include support in the kernel for pcmcia on Amiga 1200 and Amiga
-	  600. If you intend to use pcmcia cards say Y; otherwise say N.
-
-config STRAM_PROC
-	bool "ST-RAM statistics in /proc"
-	depends on ATARI
-	help
-	  Say Y here to report ST-RAM usage statistics in /proc/stram.
-
-config HEARTBEAT
-	bool "Use power LED as a heartbeat" if AMIGA || APOLLO || ATARI || MAC ||Q40
-	default y if !AMIGA && !APOLLO && !ATARI && !MAC && !Q40 && HP300
-	help
-	  Use the power-on LED on your machine as a load meter.  The exact
-	  behavior is platform-dependent, but normally the flash frequency is
-	  a hyperbolic function of the 5-minute load average.
-
-# We have a dedicated heartbeat LED. :-)
-config PROC_HARDWARE
-	bool "/proc/hardware support"
-	help
-	  Say Y here to support the /proc/hardware file, which gives you
-	  access to information about the machine you're running on,
-	  including the model, CPU, MMU, clock speed, BogoMIPS rating,
-	  and memory size.
-
-config ISA
-	bool
-	depends on Q40 || AMIGA_PCMCIA
-	default y
-	help
-	  Find out whether you have ISA slots on your motherboard.  ISA is the
-	  name of a bus system, i.e. the way the CPU talks to the other stuff
-	  inside your box.  Other bus systems are PCI, EISA, MicroChannel
-	  (MCA) or VESA.  ISA is an older system, now being displaced by PCI;
-	  newer boards don't support it.  If you have ISA, say Y, otherwise N.
-
-config GENERIC_ISA_DMA
-	bool
-	depends on Q40 || AMIGA_PCMCIA
-	default y
+endmenu
 
-config ZONE_DMA
-	bool
-	default y
+if !MMU
 
-source "drivers/pci/Kconfig"
+menu "Power management options"
 
-source "drivers/zorro/Kconfig"
+config PM
+        bool "Power Management support"
+        help
+          Support processor power management modes
 
 endmenu
 
+endif
+
 source "net/Kconfig"
 
 source "drivers/Kconfig"
 
+if MMU
+
 menu "Character devices"
 
 config ATARI_MFPSER
@@ -606,6 +247,8 @@ config SERIAL_CONSOLE
 
 endmenu
 
+endif
+
 source "fs/Kconfig"
 
 source "arch/m68k/Kconfig.debug"
arch/m68k/Kconfig.debug +34 -0
diff -Naurp linux-2.6.x.half-merge/arch/m68k/Kconfig.debug linux-2.6.x.full-merge/arch/m68k/Kconfig.debug
@@ -2,4 +2,38 @@ menu "Kernel hacking"
 
 source "lib/Kconfig.debug"
 
+if !MMU
+
+config FULLDEBUG
+	bool "Full Symbolic/Source Debugging support"
+	help
+	  Enable debugging symbols on kernel build.
+
+config HIGHPROFILE
+	bool "Use fast second timer for profiling"
+	depends on COLDFIRE
+	help
+	  Use a fast secondary clock to produce profiling information.
+
+config BOOTPARAM
+	bool 'Compiled-in Kernel Boot Parameter'
+
+config BOOTPARAM_STRING
+	string 'Kernel Boot Parameter'
+	default 'console=ttyS0,19200'
+	depends on BOOTPARAM
+
+config NO_KERNEL_MSG
+	bool "Suppress Kernel BUG Messages"
+	help
+	  Do not output any debug BUG messages within the kernel.
+
+config BDM_DISABLE
+	bool "Disable BDM signals"
+	depends on (EXPERIMENTAL && COLDFIRE)
+	help
+	  Disable the ColdFire CPU's BDM signals.
+
+endif
+
 endmenu
arch/m68k/Kconfig.mmu +386 -0

386 lines not on this page · raw message

arch/m68k/Kconfig.nommu +715 -0

715 lines not on this page · raw message

arch/m68k/Makefile_no +7 -7
diff -Naurp linux-2.6.x.half-merge/arch/m68k/Makefile_no linux-2.6.x.full-merge/arch/m68k/Makefile_no
@@ -1,5 +1,5 @@
 #
-# arch/m68knommu/Makefile
+# arch/m68k/Makefile_no
 #
 # This file is subject to the terms and conditions of the GNU General Public
 # License.  See the file "COPYING" in the main directory of this archive
@@ -82,7 +82,7 @@ cpuclass-$(CONFIG_M68360)	:= 68360
 CPUCLASS := $(cpuclass-y)
 
 ifneq ($(CPUCLASS),$(PLATFORM))
-CLASSDIR := arch/m68knommu/platform/$(cpuclass-y)/
+CLASSDIR := arch/m68k/platform/$(cpuclass-y)/
 endif
 
 export PLATFORM BOARD MODEL CPUCLASS
@@ -114,13 +114,13 @@ KBUILD_CFLAGS += $(cflags-y)
 KBUILD_CFLAGS += -D__linux__
 KBUILD_CFLAGS += -DUTS_SYSNAME=\"uClinux\"
 
-head-y := arch/m68knommu/platform/$(cpuclass-y)/head.o
+head-y := arch/m68k/platform/$(cpuclass-y)/head.o
 
-core-y	+= arch/m68knommu/kernel/ \
-	   arch/m68knommu/mm/ \
+core-y	+= arch/m68k/kernel/ \
+	   arch/m68k/mm/ \
 	   $(CLASSDIR) \
-	   arch/m68knommu/platform/$(PLATFORM)/
-libs-y	+= arch/m68knommu/lib/
+	   arch/m68k/platform/$(PLATFORM)/
+libs-y	+= arch/m68k/lib/
 
 archclean:
 
#1 lore raw
Quoted 6 lines · Greg Ungerer

Hi All,

I would like to put up for discussion a merge of the m68knommu and m68k arch branches.

Quoted 8 lines

Attached is a script and patch that does a kind of brute force simplistic merge of the directories and files. (Thanks to Stephen King <[email protected]> for the initial version of this script, and to Sam Ravnborg for the m68k includes merge script this was based on). Nothing outside of the arch/m68k and arch/m68knommu directories is touched, and in the end there is no more arch/m68knommu. To apply you simply run the script from the top of a current kernel git tree (I used 2.6.38-rc5 for testing) and then apply the patch.

The initial version of said script was created by Arnd IIRC.

Quoted 1 line

Thoughts?

When we merged x86, sh and sparc in the past this has in all cases helped sharing coe between the 32 and 64 bit variants. There has in all cases been some code-chrunch in the beginning, but the result has been good.
What as often caused some troubles has been how to configure the individual architectures.

We have for eaxample:
make ARCH=x86, make ARCH=i386, make ARCH=x86_64 today.

Likewise for sparc we have:
make ARCH=sparc, make ARCH=sparc32, make ARCH=sparc64

So you need to consider how to deal with this for m68k. Maybe MMU is just an option so you only have ARCH=m68k in the end?

You do not touch upon the maintenance of the merged trees. Today there is different maintainers for the two archs. To have a transparent flow the better solution is likely that all m68k* patches go via one of your trees so we do not have two trees that deal with m68k upstream.

I assume we will sort it all out naturally and I hope that we soon will have m68k and m68knommu merged!

Sam
_______________________________________________
uClinux-dev mailing list [email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected] To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

#5 lore raw
In reply to Greg Ungerer
Quoted 11 lines · Greg Ungerer

I would like to put up for discussion a merge of the m68knommu and m68k arch branches.

Attached is a script and patch that does a kind of brute force simplistic merge of the directories and files. (Thanks to Stephen King <[email protected]> for the initial version of this script, and to Sam Ravnborg for the m68k includes merge script this was based on). Nothing outside of the arch/m68k and arch/m68knommu directories is touched, and in the end there is no more arch/m68knommu. To apply you simply run the script from the top of a current kernel git tree (I used 2.6.38-rc5 for testing) and then apply the patch.

Initial feedback:

arch/m68k/Makefile +2 -2
@@ -1,5 +1,5 @@
 ifdef CONFIG_MMU
-include arch/m68k/Makefile_mm
+include $(srctree)/arch/m68k/Makefile_mm
 else
-include arch/m68k/Makefile_no
+include $(srctree)/arch/m68k/Makefile_no
 endif

Don't you need to add "# CONFIG_MMU is not set" to all m68knommu defconfig files?

Building...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

#2 lore raw
In reply to Sam Ravnborg

Hi Sam,

Quoted 16 lines · Sam Ravnborg
Quoted 6 lines · Greg Ungerer

Hi All,

I would like to put up for discussion a merge of the m68knommu and m68k arch branches.

Quoted 8 lines

Attached is a script and patch that does a kind of brute force simplistic merge of the directories and files. (Thanks to Stephen King <[email protected]> for the initial version of this script, and to Sam Ravnborg for the m68k includes merge script this was based on). Nothing outside of the arch/m68k and arch/m68knommu directories is touched, and in the end there is no more arch/m68knommu. To apply you simply run the script from the top of a current kernel git tree (I used 2.6.38-rc5 for testing) and then apply the patch.

Quoted 1 line

The initial version of said script was created by Arnd IIRC.

Apologies to Arnd then :-)

Quoted 8 lines
Quoted 1 line

Thoughts?

When we merged x86, sh and sparc in the past this has in all cases helped sharing coe between the 32 and 64 bit variants. There has in all cases been some code-chrunch in the beginning, but the result has been good.
What as often caused some troubles has been how to configure the individual architectures.

Quoted 8 lines

We have for eaxample:
make ARCH=x86, make ARCH=i386, make ARCH=x86_64 today.

Likewise for sparc we have:
make ARCH=sparc, make ARCH=sparc32, make ARCH=sparc64

So you need to consider how to deal with this for m68k. Maybe MMU is just an option so you only have ARCH=m68k in the end?

That is what I have currently done. CONFIG_MMU is selectable, and there is no longer a separate ARCH=m68knommu, only ARCH=m68k. I am fine with that, but I am interested in what opinion others have on this.

Quoted 5 lines

You do not touch upon the maintenance of the merged trees. Today there is different maintainers for the two archs. To have a transparent flow the better solution is likely that all m68k* patches go via one of your trees so we do not have two trees that deal with m68k upstream.

Yeah, I had much thought to this yet.

Quoted 2 lines

I assume we will sort it all out naturally and I hope that we soon will have m68k and m68knommu merged!

That would be my take on it ;-)
I am happy to charge ahead and let the maintenance/flow work itself out.

Thanks
Greg

------------------------------------------------------------------------

Greg Ungerer  --  Principal Engineer        EMAIL:     [email protected]
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close                             FAX:         +61 7 3217 5323
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com
#6 lore raw
In reply to Geert Uytterhoeven
Quoted 13 lines · Geert Uytterhoeven
Quoted 11 lines · Greg Ungerer

I would like to put up for discussion a merge of the m68knommu and m68k arch branches.

Attached is a script and patch that does a kind of brute force simplistic merge of the directories and files. (Thanks to Stephen King <[email protected]> for the initial version of this script, and to Sam Ravnborg for the m68k includes merge script this was based on). Nothing outside of the arch/m68k and arch/m68knommu directories is touched, and in the end there is no more arch/m68knommu. To apply you simply run the script from the top of a current kernel git tree (I used 2.6.38-rc5 for testing) and then apply the patch.

Quoted 1 line

Building...

Builds fine (all test configs), runs on ARAnyM.

Let's go ahead?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

#7 lore raw

Hi Geert,

Quoted 14 lines · Geert Uytterhoeven
Quoted 13 lines · Geert Uytterhoeven
Quoted 11 lines · Greg Ungerer

I would like to put up for discussion a merge of the m68knommu and m68k arch branches.

Attached is a script and patch that does a kind of brute force simplistic merge of the directories and files. (Thanks to Stephen King <[email protected]> for the initial version of this script, and to Sam Ravnborg for the m68k includes merge script this was based on). Nothing outside of the arch/m68k and arch/m68knommu directories is touched, and in the end there is no more arch/m68knommu. To apply you simply run the script from the top of a current kernel git tree (I used 2.6.38-rc5 for testing) and then apply the patch.

Quoted 5 lines
Quoted 1 line

Building...

Builds fine (all test configs), runs on ARAnyM.

Let's go ahead?

What sort of timing do you think makes sense?
Is for 2.6.39 too soon?

Regards
Greg

------------------------------------------------------------------------

Greg Ungerer  --  Principal Engineer        EMAIL:     [email protected]
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close                             FAX:         +61 7 3217 5323
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com
#8 lore raw
Quoted 18 lines · Greg Ungerer
Quoted 17 lines · Geert Uytterhoeven
Quoted 15 lines · Geert Uytterhoeven
Quoted 12 lines · Greg Ungerer

I would like to put up for discussion a merge of the m68knommu and m68k arch branches.

Attached is a script and patch that does a kind of brute force simplistic merge of the directories and files. (Thanks to Stephen King <[email protected]>  for the initial version of this script, and to Sam Ravnborg for the m68k includes merge script this was based on). Nothing outside of the arch/m68k and arch/m68knommu directories is touched, and in the end there is no more arch/m68knommu. To apply you simply run the script from the top of a current kernel git tree (I used 2.6.38-rc5 for testing) and then apply the patch.

Quoted 8 lines
Quoted 5 lines
Quoted 1 line

Building...

Builds fine (all test configs), runs on ARAnyM.

Let's go ahead?

What sort of timing do you think makes sense?
Is for 2.6.39 too soon?

Personally, I don't mind. 2.6.39 is OK for me. I guess the safest way is to let Linus
execute the script? Before or after the merge window?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

#9 lore raw

Hi Geert,

Quoted 23 lines · Geert Uytterhoeven
Quoted 22 lines · Greg Ungerer
Quoted 21 lines · Geert Uytterhoeven
Quoted 15 lines · Geert Uytterhoeven
Quoted 4 lines · Greg Ungerer

I would like to put up for discussion a merge of the m68knommu and m68k arch branches.

Quoted 8 lines

Attached is a script and patch that does a kind of brute force simplistic merge of the directories and files. (Thanks to Stephen King
<[email protected]> for the initial version of this script, and to
Sam Ravnborg for the m68k includes merge script this was based on). Nothing outside of the arch/m68k and arch/m68knommu directories is touched, and in the end there is no more arch/m68knommu. To apply you simply run the script from the top of a current kernel git tree (I used 2.6.38-rc5 for testing) and then apply the patch.

Quoted 1 line

Building...

Builds fine (all test configs), runs on ARAnyM.

Quoted 8 lines
Quoted 4 lines
Quoted 1 line

Let's go ahead?

What sort of timing do you think makes sense?
Is for 2.6.39 too soon?

Personally, I don't mind. 2.6.39 is OK for me. I guess the safest way is to let Linus
execute the script? Before or after the merge window?

Well I was going to construct the merge as a single git commit (which is equivalent to running this script and applying the patch). Linus would then just pull this.

The best timing for me is near the end of the merge window. That way we can both get in any other changes first.

Regards
Greg

------------------------------------------------------------------------

Greg Ungerer  --  Principal Engineer        EMAIL:     [email protected]
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close                             FAX:         +61 7 3217 5323
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com

_______________________________________________
uClinux-dev mailing list [email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected] To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

#10 lore raw
Quoted 38 lines · Greg Ungerer
Quoted 28 lines · Geert Uytterhoeven
Quoted 26 lines · Greg Ungerer
Quoted 24 lines · Geert Uytterhoeven
Quoted 17 lines · Geert Uytterhoeven
Quoted 4 lines · Greg Ungerer

I would like to put up for discussion a merge of the m68knommu and m68k arch branches.

Quoted 9 lines

Attached is a script and patch that does a kind of brute force simplistic merge of the directories and files. (Thanks to Stephen King <[email protected]>    for the initial version of this script, and to Sam Ravnborg for the m68k includes merge script this was based on). Nothing outside of the arch/m68k and arch/m68knommu directories is touched, and in the end there is no more arch/m68knommu. To apply you simply run the script from the top of a current kernel git tree (I used
2.6.38-rc5 for testing) and then apply the patch.

Quoted 1 line

Building...

Builds fine (all test configs), runs on ARAnyM.

Quoted 8 lines
Quoted 4 lines
Quoted 1 line

Let's go ahead?

What sort of timing do you think makes sense?
Is for 2.6.39 too soon?

Personally, I don't mind. 2.6.39 is OK for me. I guess the safest way is to let Linus
execute the script? Before or after the merge window?

Quoted 6 lines

Well I was going to construct the merge as a single git commit (which is equivalent to running this script and applying the patch). Linus would then just pull this.

The best timing for me is near the end of the merge window. That way we can both get in any other changes first.

Sounds like a plan, OK!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

#13 lore raw
In reply to Greg Ungerer
Quoted 9 lines · Greg Ungerer

Inside of the new arch/m68k is a little messy in the kernel and mm directories. There is plenty of scope for cleanup and merge on the files in here - but I want to leave that for follow up patches after this initial directory merge. As a data point, when we merged the m68k and m68knommu include files we had something like 70 or 80 duplicate but separate files, after some cleanups that is now down to
10. Ongoing cleanup will merge some of these remaining ones as well.

Thoughts?

Hmm, how are you going to deal with the fact, that m68knommu uses genirq, m68k not? I guess there are some more points like this (clockevents, clocksource ...)

Is there a plan to move m68k to the generic facilities as well ?

Thanks,

tglx

#3 lore raw
In reply to Greg Ungerer
Quoted 9 lines · On Friday 18 February 2011 13:01:53 Greg Ungerer wrote:
Quoted 9 lines
Quoted 8 lines

Attached is a script and patch that does a kind of brute force simplistic merge of the directories and files. (Thanks to Stephen King <[email protected]> for the initial version of this script, and to Sam Ravnborg for the m68k includes merge script this was based on). Nothing outside of the arch/m68k and arch/m68knommu directories is touched, and in the end there is no more arch/m68knommu. To apply you simply run the script from the top of a current kernel git tree (I used 2.6.38-rc5 for testing) and then apply the patch.

Quoted 3 lines
Quoted 1 line

The initial version of said script was created by Arnd IIRC.

Apologies to Arnd then :-)

I had absolutely no memory of having done said script, but if Sam says wrote it did, that's probably true.

I was just about to say how much I like your script when I read that it was my idea...

Arnd

#4 lore raw
Quoted 12 lines · Arnd Bergmann
Quoted 11 lines · On Friday 18 February 2011 13:01:53 Greg Ungerer wrote:
Quoted 10 lines
Quoted 8 lines

Attached is a script and patch that does a kind of brute force simplistic merge of the directories and files. (Thanks to Stephen King <[email protected]> for the initial version of this script, and to Sam Ravnborg for the m68k includes merge script this was based on). Nothing outside of the arch/m68k and arch/m68knommu directories is touched, and in the end there is no more arch/m68knommu. To apply you simply run the script from the top of a current kernel git tree (I used 2.6.38-rc5 for testing) and then apply the patch.

The initial version of said script was created by Arnd IIRC.

Quoted 7 lines
Quoted 1 line

Apologies to Arnd then :-)

I had absolutely no memory of having done said script, but if Sam says wrote it did, that's probably true.

I was just about to say how much I like your script when I read that it was my idea...

See semi original version in: 49148020bcb6910ce71417bd990a5ce7017f9bd3

Sam

#14 lore raw
In reply to Thomas Gleixner

Hi Thomas,

Quoted 9 lines · Thomas Gleixner
Quoted 8 lines · Greg Ungerer

Inside of the new arch/m68k is a little messy in the kernel and mm directories. There is plenty of scope for cleanup and merge on the files in here - but I want to leave that for follow up patches after this initial directory merge. As a data point, when we merged the m68k and m68knommu include files we had something like 70 or 80 duplicate but separate files, after some cleanups that is now down to
10. Ongoing cleanup will merge some of these remaining ones as well.

Quoted 5 lines
Quoted 1 line

Thoughts?

Hmm, how are you going to deal with the fact, that m68knommu uses genirq, m68k not? I guess there are some more points like this (clockevents, clocksource ...)

Initially it has no impact. This first step pretty much just combines the 2 directories, it doesn't attempt to do a fine grained merge of each file. (It does factor out identical files - quite a few in arch/m68k/lib for example).

Quoted 1 line

Is there a plan to move m68k to the generic facilities as well ?

I'll look at doing what I can as I work through merging all the underlying pieces :-)

Regards
Greg

------------------------------------------------------------------------

Greg Ungerer  --  Principal Engineer        EMAIL:     [email protected]
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close                             FAX:         +61 7 3217 5323
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com
#15 lore raw
Quoted 12 lines · Greg Ungerer
Quoted 11 lines · Thomas Gleixner
Quoted 9 lines · Greg Ungerer

Inside of the new arch/m68k is a little messy in the kernel and mm directories. There is plenty of scope for cleanup and merge on the files in here - but I want to leave that for follow up patches after this initial directory merge. As a data point, when we merged the m68k and m68knommu include files we had something like 70 or 80 duplicate but separate files, after some cleanups that is now down to
10. Ongoing cleanup will merge some of these remaining ones as well.

Thoughts?

Quoted 11 lines
Quoted 3 lines

Hmm, how are you going to deal with the fact, that m68knommu uses genirq, m68k not? I guess there are some more points like this (clockevents, clocksource ...)

Initially it has no impact. This first step pretty much just combines the 2 directories, it doesn't attempt to do a fine grained merge of each file. (It does factor out identical files - quite a few in arch/m68k/lib for example).

Quoted 1 line

Is there a plan to move m68k to the generic facilities as well ?

Moving m68k to genirq is (the next thing?) on my list...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

#16 lore raw
Quoted 5 lines
Quoted 3 lines
Quoted 3 lines

Is there a plan to move m68k to the generic facilities as well ?

Moving m68k to genirq is (the next thing?) on my list...

If I succeed migrating sparc32 to genirq I hope to be of a little help here. It looks like a bigger task to migrate m68k than it was/is to migrate sparc32.

It would be _very_ nice to get the last two architectures migrated to genirq.

Sam
_______________________________________________
uClinux-dev mailing list [email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected] To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

#17 lore raw
Quoted 8 lines · Sam Ravnborg
Quoted 3 lines
Quoted 1 line
Quoted 1 line

Is there a plan to move m68k to the generic facilities as well ?

Moving m68k to genirq is (the next thing?) on my list...

If I succeed migrating sparc32 to genirq I hope to be of a little help here. It looks like a bigger task to migrate m68k than it was/is to migrate sparc32.

It would be _very_ nice to get the last two architectures migrated to genirq.

Aren't your forgetting s390?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

#18 lore raw
Quoted 11 lines · Geert Uytterhoeven
Quoted 8 lines · Sam Ravnborg
Quoted 3 lines
Quoted 1 line
Quoted 1 line

Is there a plan to move m68k to the generic facilities as well ?

Moving m68k to genirq is (the next thing?) on my list...

If I succeed migrating sparc32 to genirq I hope to be of a little help here. It looks like a bigger task to migrate m68k than it was/is to migrate sparc32.

It would be _very_ nice to get the last two architectures migrated to genirq.

Aren't your forgetting s390?

Hmm, I had the understanding that m68k and sparc32 was the only two remaining :-( But I did not check.

s390 sees more active maintenance so if they become the last non genirq user, then they may feel a bit of pressure :-)

Sam

#19 lore raw
In reply to Greg Ungerer

Greg,

Quoted 12 lines · Greg Ungerer
Quoted 11 lines · Thomas Gleixner
Quoted 9 lines · Greg Ungerer

Inside of the new arch/m68k is a little messy in the kernel and mm directories. There is plenty of scope for cleanup and merge on the files in here - but I want to leave that for follow up patches after this initial directory merge. As a data point, when we merged the m68k and m68knommu include files we had something like 70 or 80 duplicate but separate files, after some cleanups that is now down to
10. Ongoing cleanup will merge some of these remaining ones as well.

Thoughts?

Quoted 8 lines
Quoted 3 lines

Hmm, how are you going to deal with the fact, that m68knommu uses genirq, m68k not? I guess there are some more points like this (clockevents, clocksource ...)

Initially it has no impact. This first step pretty much just combines the 2 directories, it doesn't attempt to do a fine grained merge of each file. (It does factor out identical files - quite a few in arch/m68k/lib for example).

Ah, ok. So you doing it similar to the plain move approach which we did with x86 back then.

Quoted 4 lines
Quoted 1 line

Is there a plan to move m68k to the generic facilities as well ?

I'll look at doing what I can as I work through merging all the underlying pieces :-)

Fair enough.

Thanks,

tglx

#11 lore raw
In reply to Geert Uytterhoeven

Hi Geert,

Looks like we both have our changes for m68k and m68knommu in Linus' git tree for this merge window. Do you plan to push anything else?

If you are done I will prepare a single git commit on the m68knommu git tree that merges the m68knommu and m68k arch branches. I will post here again for one last check over early next week, and if everyone is happy I will ask Linus to pull it later next week.

How does that sound?

Regards
Greg

------------------------------------------------------------------------

Greg Ungerer  --  Principal Engineer        EMAIL:     [email protected]
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close                             FAX:         +61 7 3217 5323
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com
#12 lore raw

Hi Greg,

Quoted 2 lines · Greg Ungerer

Looks like we both have our changes for m68k and m68knommu in Linus' git tree for this merge window. Do you plan to push anything else?

Nothing planned for now.

Quoted 6 lines

If you are done I will prepare a single git commit on the m68knommu git tree that merges the m68knommu and m68k arch branches. I will post here again for one last check over early next week, and if everyone is happy I will ask Linus to pull it later next week.

How does that sound?

Sounds great! Thx!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev