All of lore.kernel.org
 help / color / mirror / Atom feed
* [GIT PULL] arch: remove obsolete architecture ports
@ 2018-04-02  7:17 Arnd Bergmann
  2018-04-02 18:57 ` Linus Torvalds
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Arnd Bergmann @ 2018-04-02  7:17 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Linux Kernel Mailing List, linux-arch, James Hogan,
	David Howells, linux-am33-list, Hirokazu Takata, Lennox Wu,
	Aaron Wu, Bryan Wu, Chris Metcalf, Jesper Nilsson

Hi Linus,

The series is rather long and conflicts in trivial ways with lots
of subsystem trees. You probably want to pull it either really
early in the merge window or really late.

     Arnd

----
The following changes since commit 661e50bc853209e41a5c14a290ca4decc43cbfd1:

  Linux 4.16-rc4 (2018-03-04 14:54:11 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git
tags/arch-removal

for you to fetch changes up to dd3b8c329aa270027fba61a02a12600972dc3983:

  MAINTAINERS: UNICORE32: Change email account (2018-03-26 15:57:29 +0200)

----------------------------------------------------------------
arch: remove obsolete architecture ports

This removes the entire architecture code for blackfin, cris, frv, m32r,
metag, mn10300, score, and tile, including the associated device drivers.

I have been working with the (former) maintainers for each one to ensure
that my interpretation was right and the code is definitely unused in
mainline kernels. Many had fond memories of working on the respective
ports to start with and getting them included in upstream, but also saw
no point in keeping the port alive without any users.

In the end, it seems that while the eight architectures are extremely
different, they all suffered the same fate: There was one company
in charge of an SoC line, a CPU microarchitecture and a software
ecosystem, which was more costly than licensing newer off-the-shelf
CPU cores from a third party (typically ARM, MIPS, or RISC-V). It seems
that all the SoC product lines are still around, but have not used the
custom CPU architectures for several years at this point. In contrast,
CPU instruction sets that remain popular and have actively maintained
kernel ports tend to all be used across multiple licensees.

The removal came out of a discussion that is now documented at
https://lwn.net/Articles/748074/. Unlike the original plans, I'm not
marking any ports as deprecated but remove them all at once after I made
sure that they are all unused. Some architectures (notably tile, mn10300,
and blackfin) are still being shipped in products with old kernels,
but those products will never be updated to newer kernel releases.

After this series, we still have a few architectures without mainline
gcc support:

- unicore32 and hexagon both have very outdated gcc releases, but the
  maintainers promised to work on providing something newer. At least
  in case of hexagon, this will only be llvm, not gcc.

- openrisc, risc-v and nds32 are still in the process of finishing their
  support or getting it added to mainline gcc in the first place.
  They all have patched gcc-7.3 ports that work to some degree, but
  complete upstream support won't happen before gcc-8.1. Csky posted
  their first kernel patch set last week, their situation will be similar.

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

(dirstat only for brevity)

   0.0% Documentation/admin-guide/
   0.0% Documentation/blackfin/
   0.0% Documentation/cris/
   0.0% Documentation/dev-tools/
   0.0% Documentation/devicetree/bindings/cris/
   0.0% Documentation/devicetree/bindings/gpio/
   0.0% Documentation/devicetree/bindings/interrupt-controller/
   0.0% Documentation/devicetree/bindings/metag/
   0.0% Documentation/devicetree/bindings/serial/
   0.0% Documentation/driver-api/usb/
   0.0% Documentation/features/core/BPF-JIT/
   0.0% Documentation/features/core/generic-idle-thread/
   0.0% Documentation/features/core/jump-labels/
   0.0% Documentation/features/core/tracehook/
   0.0% Documentation/features/debug/KASAN/
   0.0% Documentation/features/debug/gcov-profile-all/
   0.0% Documentation/features/debug/kgdb/
   0.0% Documentation/features/debug/kprobes-on-ftrace/
   0.0% Documentation/features/debug/kprobes/
   0.0% Documentation/features/debug/kretprobes/
   0.0% Documentation/features/debug/optprobes/
   0.0% Documentation/features/debug/stackprotector/
   0.0% Documentation/features/debug/uprobes/
   0.0% Documentation/features/debug/user-ret-profiler/
   0.0% Documentation/features/io/dma-api-debug/
   0.0% Documentation/features/io/dma-contiguous/
   0.0% Documentation/features/io/sg-chain/
   0.0% Documentation/features/lib/strncasecmp/
   0.0% Documentation/features/locking/cmpxchg-local/
   0.0% Documentation/features/locking/lockdep/
   0.0% Documentation/features/locking/queued-rwlocks/
   0.0% Documentation/features/locking/queued-spinlocks/
   0.0% Documentation/features/locking/rwsem-optimized/
   0.0% Documentation/features/perf/kprobes-event/
   0.0% Documentation/features/perf/perf-regs/
   0.0% Documentation/features/perf/perf-stackdump/
   0.0% Documentation/features/sched/membarrier-sync-core/
   0.0% Documentation/features/sched/numa-balancing/
   0.0% Documentation/features/seccomp/seccomp-filter/
   0.0% Documentation/features/time/arch-tick-broadcast/
   0.0% Documentation/features/time/clockevents/
   0.0% Documentation/features/time/context-tracking/
   0.0% Documentation/features/time/irq-time-acct/
   0.0% Documentation/features/time/modern-timekeeping/
   0.0% Documentation/features/time/virt-cpuacct/
   0.0% Documentation/features/vm/ELF-ASLR/
   0.0% Documentation/features/vm/PG_uncached/
   0.0% Documentation/features/vm/THP/
   0.0% Documentation/features/vm/TLB/
   0.0% Documentation/features/vm/huge-vmap/
   0.0% Documentation/features/vm/ioremap_prot/
   0.0% Documentation/features/vm/numa-memblock/
   0.0% Documentation/features/vm/pte_special/
   0.4% Documentation/frv/
   0.0% Documentation/ioctl/
   0.0% Documentation/metag/
   0.0% Documentation/mn10300/
   0.0% Documentation/watchdog/
   0.0% Documentation/
   0.0% arch/blackfin/boot/
   0.5% arch/blackfin/configs/
   2.3% arch/blackfin/include/asm/
   0.0% arch/blackfin/include/mach-common/
   0.1% arch/blackfin/include/uapi/asm/
   0.0% arch/blackfin/kernel/cplb-mpu/
   0.0% arch/blackfin/kernel/cplb-nompu/
   2.2% arch/blackfin/kernel/
   0.2% arch/blackfin/lib/
   0.2% arch/blackfin/mach-bf518/boards/
   1.5% arch/blackfin/mach-bf518/include/mach/
   0.0% arch/blackfin/mach-bf518/
   0.7% arch/blackfin/mach-bf527/boards/
   2.0% arch/blackfin/mach-bf527/include/mach/
   0.0% arch/blackfin/mach-bf527/
   0.4% arch/blackfin/mach-bf533/boards/
   0.8% arch/blackfin/mach-bf533/include/mach/
   0.0% arch/blackfin/mach-bf533/
   1.0% arch/blackfin/mach-bf537/boards/
   2.1% arch/blackfin/mach-bf537/include/mach/
   0.0% arch/blackfin/mach-bf537/
   0.1% arch/blackfin/mach-bf538/boards/
   1.9% arch/blackfin/mach-bf538/include/mach/
   0.0% arch/blackfin/mach-bf538/
   0.5% arch/blackfin/mach-bf548/boards/
   5.4% arch/blackfin/mach-bf548/include/mach/
   0.1% arch/blackfin/mach-bf548/
   0.2% arch/blackfin/mach-bf561/boards/
   1.6% arch/blackfin/mach-bf561/include/mach/
   0.2% arch/blackfin/mach-bf561/
   0.3% arch/blackfin/mach-bf609/boards/
   3.8% arch/blackfin/mach-bf609/include/mach/
   0.4% arch/blackfin/mach-bf609/
   0.8% arch/blackfin/mach-common/
   0.2% arch/blackfin/mm/
   0.0% arch/blackfin/oprofile/
   0.3% arch/blackfin/
   0.8% arch/cris/arch-v10/drivers/
   1.3% arch/cris/arch-v10/kernel/
   0.2% arch/cris/arch-v10/lib/
   0.1% arch/cris/arch-v10/mm/
   0.1% arch/cris/arch-v10/
   0.0% arch/cris/arch-v32/drivers/mach-a3/
   0.0% arch/cris/arch-v32/drivers/mach-fs/
   0.0% arch/cris/arch-v32/drivers/pci/
   1.2% arch/cris/arch-v32/drivers/
   1.2% arch/cris/arch-v32/kernel/
   0.2% arch/cris/arch-v32/lib/
   0.2% arch/cris/arch-v32/mach-a3/
   0.2% arch/cris/arch-v32/mach-fs/
   0.1% arch/cris/arch-v32/mm/
   0.0% arch/cris/arch-v32/
   0.1% arch/cris/boot/compressed/
   0.0% arch/cris/boot/dts/
   0.1% arch/cris/boot/rescue/
   0.0% arch/cris/boot/tools/
   0.0% arch/cris/boot/
   0.0% arch/cris/configs/
   0.3% arch/cris/include/arch-v10/arch/
   1.4% arch/cris/include/arch-v32/arch/hwregs/asm/
   2.9% arch/cris/include/arch-v32/arch/hwregs/iop/asm/
   1.8% arch/cris/include/arch-v32/arch/hwregs/iop/
   0.9% arch/cris/include/arch-v32/arch/hwregs/
   0.3% arch/cris/include/arch-v32/arch/
   0.7% arch/cris/include/arch-v32/mach-a3/mach/hwregs/asm/
   1.2% arch/cris/include/arch-v32/mach-a3/mach/hwregs/iop/asm/
   0.6% arch/cris/include/arch-v32/mach-a3/mach/hwregs/iop/
   0.8% arch/cris/include/arch-v32/mach-a3/mach/hwregs/
   0.0% arch/cris/include/arch-v32/mach-a3/mach/
   0.4% arch/cris/include/arch-v32/mach-fs/mach/hwregs/asm/
   0.6% arch/cris/include/arch-v32/mach-fs/mach/hwregs/
   0.0% arch/cris/include/arch-v32/mach-fs/mach/
   0.3% arch/cris/include/asm/
   2.0% arch/cris/include/uapi/arch-v10/arch/
   0.0% arch/cris/include/uapi/arch-v32/arch/
   0.3% arch/cris/include/uapi/asm/
   0.2% arch/cris/kernel/
   0.1% arch/cris/mm/
   0.1% arch/cris/
   0.0% arch/frv/boot/
   1.3% arch/frv/include/asm/
   0.2% arch/frv/include/uapi/asm/
   2.3% arch/frv/kernel/
   0.2% arch/frv/lib/
   0.1% arch/frv/mb93090-mb00/
   0.3% arch/frv/mm/
   0.0% arch/frv/
   0.0% arch/m32r/boot/compressed/
   0.0% arch/m32r/boot/
   0.1% arch/m32r/configs/
   0.0% arch/m32r/include/asm/m32104ut/
   0.1% arch/m32r/include/asm/m32700ut/
   0.0% arch/m32r/include/asm/mappi2/
   0.0% arch/m32r/include/asm/mappi3/
   0.0% arch/m32r/include/asm/opsput/
   1.2% arch/m32r/include/asm/
   0.2% arch/m32r/include/uapi/asm/
   0.9% arch/m32r/kernel/
   0.2% arch/m32r/lib/
   0.2% arch/m32r/mm/
   0.0% arch/m32r/oprofile/
   0.0% arch/m32r/platforms/m32104ut/
   0.2% arch/m32r/platforms/m32700ut/
   0.2% arch/m32r/platforms/mappi/
   0.1% arch/m32r/platforms/mappi2/
   0.1% arch/m32r/platforms/mappi3/
   0.0% arch/m32r/platforms/oaks32r/
   0.1% arch/m32r/platforms/opsput/
   0.0% arch/m32r/platforms/usrv/
   0.0% arch/m32r/platforms/
   0.0% arch/m32r/
   0.0% arch/metag/boot/dts/
   0.0% arch/metag/boot/
   0.0% arch/metag/configs/
   0.0% arch/metag/include/asm/mach/
   1.9% arch/metag/include/asm/
   0.0% arch/metag/include/uapi/asm/
   0.1% arch/metag/kernel/perf/
   1.0% arch/metag/kernel/
   0.4% arch/metag/lib/
   0.4% arch/metag/mm/
   0.0% arch/metag/oprofile/
   0.4% arch/metag/tbx/
   0.0% arch/metag/
   0.0% arch/mn10300/boot/compressed/
   0.0% arch/mn10300/boot/tools/
   0.0% arch/mn10300/boot/
   0.0% arch/mn10300/configs/
   1.5% arch/mn10300/include/asm/
   0.2% arch/mn10300/include/uapi/asm/
   2.0% arch/mn10300/kernel/
   0.1% arch/mn10300/lib/
   0.9% arch/mn10300/mm/
   0.0% arch/mn10300/oprofile/
   0.0% arch/mn10300/proc-mn103e010/include/proc/
   0.0% arch/mn10300/proc-mn103e010/
   0.1% arch/mn10300/proc-mn2ws0050/include/proc/
   0.0% arch/mn10300/proc-mn2ws0050/
   0.0% arch/mn10300/unit-asb2303/include/unit/
   0.0% arch/mn10300/unit-asb2303/
   0.0% arch/mn10300/unit-asb2305/include/unit/
   0.1% arch/mn10300/unit-asb2305/
   0.1% arch/mn10300/unit-asb2364/include/unit/
   0.0% arch/mn10300/unit-asb2364/
   0.1% arch/mn10300/
   0.0% arch/score/boot/
   0.0% arch/score/configs/
   0.4% arch/score/include/asm/
   0.0% arch/score/include/uapi/asm/
   0.4% arch/score/kernel/
   0.1% arch/score/lib/
   0.1% arch/score/mm/
   0.0% arch/score/
   0.1% arch/tile/configs/
   0.4% arch/tile/gxio/
   0.5% arch/tile/include/arch/
   1.9% arch/tile/include/asm/
   0.7% arch/tile/include/gxio/
   2.0% arch/tile/include/hv/
   1.1% arch/tile/include/uapi/arch/
   0.1% arch/tile/include/uapi/asm/
   0.0% arch/tile/kernel/vdso/
   5.3% arch/tile/kernel/
   0.0% arch/tile/kvm/
   0.6% arch/tile/lib/
   0.7% arch/tile/mm/
   0.1% arch/tile/
   0.0% block/
   0.0% crypto/
   0.3% drivers/ata/
   0.1% drivers/char/
   0.0% drivers/clocksource/
   0.0% drivers/cpufreq/
   0.0% drivers/edac/
   0.0% drivers/gpio/
   0.1% drivers/i2c/busses/
   0.0% drivers/ide/
   0.0% drivers/input/joystick/
   0.0% drivers/input/keyboard/
   0.0% drivers/input/misc/
   0.2% drivers/irqchip/
   0.0% drivers/isdn/hisax/
   0.2% drivers/media/platform/blackfin/
   0.1% drivers/media/platform/
   0.0% drivers/media/rc/img-ir/
   0.0% drivers/misc/echo/
   0.1% drivers/mmc/host/
   0.1% drivers/net/can/
   0.3% drivers/net/cris/
   0.0% drivers/net/ethernet/8390/
   0.3% drivers/net/ethernet/adi/
   0.0% drivers/net/ethernet/davicom/
   0.0% drivers/net/ethernet/smsc/
   0.8% drivers/net/ethernet/tile/
   0.0% drivers/net/ethernet/
   0.0% drivers/net/wireless/cisco/
   0.0% drivers/net/
   0.0% drivers/pci/
   0.3% drivers/pcmcia/
   0.4% drivers/pinctrl/
   0.0% drivers/pwm/
   0.1% drivers/rtc/
   0.5% drivers/spi/
   0.0% drivers/staging/iio/trigger/
   0.0% drivers/staging/iio/
   0.0% drivers/staging/speakup/
   0.0% drivers/tty/hvc/
   1.7% drivers/tty/serial/
   0.1% drivers/tty/
   0.0% drivers/usb/gadget/function/
   0.0% drivers/usb/gadget/legacy/
   0.0% drivers/usb/host/
   0.1% drivers/usb/musb/
   0.0% drivers/video/console/
   0.7% drivers/video/fbdev/
   1.2% drivers/video/logo/
   0.0% drivers/watchdog/
   0.0% fs/minix/
   0.0% fs/proc/
   0.0% fs/
   0.0% include/asm-generic/
   0.0% include/clocksource/
   0.0% include/linux/irqchip/
   0.0% include/linux/platform_data/
   0.0% include/linux/raid/
   0.0% include/linux/usb/
   0.0% include/linux/
   0.0% include/media/blackfin/
   0.0% include/trace/events/
   0.0% include/uapi/asm-generic/
   0.0% include/uapi/linux/
   0.0% init/
   0.0% kernel/
   0.0% lib/raid6/test/
   0.0% lib/raid6/
   0.0% lib/
   0.0% mm/
   0.0% samples/blackfin/
   0.0% samples/kprobes/
   0.0% samples/
   0.0% scripts/mod/
   0.0% scripts/
   0.0% tools/arch/frv/include/uapi/asm/
   0.0% tools/arch/m32r/include/uapi/asm/
   0.0% tools/arch/mn10300/include/uapi/asm/
   0.0% tools/arch/score/include/uapi/asm/
   0.0% tools/arch/tile/include/asm/
   0.0% tools/arch/tile/include/uapi/asm/
   0.0% tools/include/asm-generic/
   0.0% tools/perf/
   0.0% tools/scripts/
   0.0% tools/testing/ktest/examples/
   0.0% tools/testing/ktest/
 2498 files changed, 95 insertions(+), 467668 deletions(-)

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [GIT PULL] arch: remove obsolete architecture ports
  2018-04-02  7:17 [GIT PULL] arch: remove obsolete architecture ports Arnd Bergmann
@ 2018-04-02 18:57 ` Linus Torvalds
  2018-04-02 19:54   ` Arnd Bergmann
  2018-04-03  2:57 ` Palmer Dabbelt
  2018-04-03  4:08 ` Linus Torvalds
  2 siblings, 1 reply; 9+ messages in thread
From: Linus Torvalds @ 2018-04-02 18:57 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Linux Kernel Mailing List, linux-arch, James Hogan,
	David Howells, linux-am33-list, Hirokazu Takata, Lennox Wu,
	Aaron Wu, Bryan Wu, Chris Metcalf, Jesper Nilsson

On Mon, Apr 2, 2018 at 12:17 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> (dirstat only for brevity)

Shortlog?

I'd like to see that each architecture removal is independent of the
others, so that if somebody wants to resurrect any particular
architecture, he/she can do so with a revert.

Can I just fetch things and see? Sure. But there's no excuse not to
have a shortlog in the pull request, even if the full diffstat itself
might be prohibitive.

                Linus

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [GIT PULL] arch: remove obsolete architecture ports
  2018-04-02 18:57 ` Linus Torvalds
@ 2018-04-02 19:54   ` Arnd Bergmann
  2018-04-03  9:18     ` Geert Uytterhoeven
  0 siblings, 1 reply; 9+ messages in thread
From: Arnd Bergmann @ 2018-04-02 19:54 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Linux Kernel Mailing List, linux-arch, James Hogan,
	David Howells, linux-am33-list, Hirokazu Takata, Lennox Wu,
	Aaron Wu, Bryan Wu, Chris Metcalf, Jesper Nilsson

On Mon, Apr 2, 2018 at 8:57 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Apr 2, 2018 at 12:17 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> (dirstat only for brevity)
>
> Shortlog?
>
> I'd like to see that each architecture removal is independent of the
> others, so that if somebody wants to resurrect any particular
> architecture, he/she can do so with a revert.
>
> Can I just fetch things and see? Sure. But there's no excuse not to
> have a shortlog in the pull request, even if the full diffstat itself
> might be prohibitive.

Right, that was a mistake on my end, I just cut too much, see below
for the missing shortlog.

Regarding a possible revert, that would indeed involve reverting
multiple patches for most architectures, plus parts of at least these
three:

  Documentation: arch-support: remove obsolete architectures
  treewide: simplify Kconfig dependencies for removed archs
  ktest: remove obsolete architectures

For those, I went the other way, and removed all architectures at
once to simplify my work and to avoid touching the same files up
to eight times with interdependent patches (which couldn't
be reverted without conflicts either).

There are a couple of driver removal patches that got picked up
into subsystem trees instead of this tree, so a full revert would also
involve finding other drivers, but if you prefer to have the patches
completely split up by arch, I could rework the series that way.

      Arnd

Aaron Wu (2):
      misc: Remove Blackfin DSP echo support
      usb: Remove Blackfin references in USB support

Arnd Bergmann (58):
      Merge tag 'metag_remove_2' of
ssh://gitolite.kernel.org/.../jhogan/metag into asm-generic
      arch: remove frv port
      arch: remove m32r port
      arch: remove score port
      arch: remove blackfin port
      arch: remove tile port
      procfs: remove CONFIG_HARDWALL dependency
      mm: remove blackfin MPU support
      mm: remove obsolete alloc_remap()
      treewide: simplify Kconfig dependencies for removed archs
      asm-generic: siginfo: remove obsolete #ifdefs
      asm-generic: siginfo: define ia64 si_codes unconditionally
      asm-generic: clean up asm/unistd.h
      Documentation: arch-support: remove obsolete architectures
      recordmcount.pl: drop blackin and tile support
      ktest: remove obsolete architectures
      edac: remove tile driver
      net: tile: remove ethernet drivers
      net: adi: remove blackfin ethernet drivers
      net: 8390: remove m32r specific bits
      net: remove cris etrax ethernet driver
      net: smsc: remove m32r/mn10300 specific smc91x configuration
      raid: remove tile specific raid6 implementation
      rtc: remove tile driver
      rtc: remove bfin driver
      char: remove obsolete ds1302 rtc driver
      char: remove tile-srom.c
      char: remove blackfin OTP driver
      pcmcia: remove m32r drivers
      pcmcia: remove blackfin driver
      video/logo: remove obsolete logo files
      fbdev: remove blackfin drivers
      fbdev: s1d13xxxfb: remove m32r specific hacks
      media: platform: remove blackfin capture driver
      media: platform: remove m32r specific arv driver
      cpufreq: remove blackfin driver
      cpufreq: remove cris specific drivers
      gpio: remove etraxfs driver
      pinctrl: remove adi2/blackfin drivers
      ata: remove bf54x driver
      input: keyboard: remove bf54x driver
      input: misc: remove blackfin rotary driver
      mmc: remove bfin_sdh driver
      can: remove bfin_can driver
      watchdog: remove bfin_wdt driver
      spi: remove blackfin related host drivers
      i2c: remove bfin-twi driver
      pwm: remove pwm-bfin driver
      usb: host: remove tilegx platform glue
      usb: musb: remove blackfin port
      usb: isp1362: remove blackfin arch glue
      serial: remove cris/etrax uart drivers
      serial: remove blackfin drivers
      serial: remove m32r_sio driver
      serial: remove tile uart driver
      tty: remove bfin_jtag_comm and hvc_bfin_jtag drivers
      tty: hvc: remove tile driver
      staging: iio: remove iio-trig-bfin-timer driver

David Howells (1):
      mn10300: Remove the architecture

Guan Xuetao (1):
      MAINTAINERS: UNICORE32: Change email account

James Hogan (11):
      metag: Remove arch/metag/
      docs: Remove metag docs
      docs: Remove remaining references to metag
      Drop a bunch of metag references
      irqchip: Remove metag irqchip drivers
      clocksource: Remove metag generic timer driver
      tty: Remove metag DA TTY and console driver
      MAINTAINERS/CREDITS: Drop METAG ARCHITECTURE
      watchdog: imgpdc: Drop METAG dependency
      media: img-ir: Drop METAG dependency
      i2c: img-scb: Drop METAG dependency

Jesper Nilsson (1):
      CRIS: Drop support for the CRIS port

Tobias Klauser (1):
      scripts/checkstack.pl: remove blackfin support

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [GIT PULL] arch: remove obsolete architecture ports
  2018-04-02  7:17 [GIT PULL] arch: remove obsolete architecture ports Arnd Bergmann
  2018-04-02 18:57 ` Linus Torvalds
@ 2018-04-03  2:57 ` Palmer Dabbelt
  2018-04-03  4:08 ` Linus Torvalds
  2 siblings, 0 replies; 9+ messages in thread
From: Palmer Dabbelt @ 2018-04-03  2:57 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Linus Torvalds, linux-kernel, linux-arch, jhogan, dhowells,
	linux-am33-list, takata, lennox.wu, Aaron.Wu, cooloney,
	chris.d.metcalf, jesper.nilsson

On Mon, 02 Apr 2018 00:17:30 PDT (-0700), Arnd Bergmann wrote:
> - openrisc, risc-v and nds32 are still in the process of finishing their
>   support or getting it added to mainline gcc in the first place.
>   They all have patched gcc-7.3 ports that work to some degree, but
>   complete upstream support won't happen before gcc-8.1. Csky posted
>   their first kernel patch set last week, their situation will be similar.

FWIW, RISC-V landed in GCC 7.  The 7.3.0 release (and binutils-2.30) is the 
first one we recommend for kernel development as there have been a handful of 
bug fixes, but there's nothing major.  SiFive ships GCC versions with a few 
extra patches applied, and while I still recommend people use these they should 
all be performance improvements at this point.  With compilers you never know 
if a performance improvement is hiding a bug, but what's tagged as gcc-7.3.0 
passes the test suite.

Our 32-bit glibc port isn't upstream yet, but our 32-bit kernel is a bit of a 
mess so that's not the blocking issue in rv32-land right now :).

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [GIT PULL] arch: remove obsolete architecture ports
  2018-04-02  7:17 [GIT PULL] arch: remove obsolete architecture ports Arnd Bergmann
  2018-04-02 18:57 ` Linus Torvalds
  2018-04-03  2:57 ` Palmer Dabbelt
@ 2018-04-03  4:08 ` Linus Torvalds
  2 siblings, 0 replies; 9+ messages in thread
From: Linus Torvalds @ 2018-04-03  4:08 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Linux Kernel Mailing List, linux-arch, James Hogan,
	David Howells, linux-am33-list, Hirokazu Takata, Lennox Wu,
	Aaron Wu, Bryan Wu, Chris Metcalf, Jesper Nilsson

On Mon, Apr 2, 2018 at 12:17 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> The series is rather long and conflicts in trivial ways with lots
> of subsystem trees. You probably want to pull it either really
> early in the merge window or really late.

Ok, I've been pulling arch updates, so it went in now.

Side note: the most concise yet useful form of diff I found for your
pull request was this:

    git diff -M --stat=5000 --summary merge^..merge | grep '\+'

which shows the diffstat, but skips anything that doesn't have a plus
sign in it. So all the pure removal lines are entirely gone.

So it shows stuff that had actual modifications, and perhaps more
importantly, it still shows the final summary, which matches yours:

 2498 files changed, 95 insertions(+), 467668 deletions(-)

which is pretty nice to see. Closer to hal a million lines gone. (Or,
as the drm people would say "one header file").

You should probably check the end result (I haven't pushed out yet,
doing a few more things and build tests, but it should be out soon).

            Linus

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [GIT PULL] arch: remove obsolete architecture ports
  2018-04-02 19:54   ` Arnd Bergmann
@ 2018-04-03  9:18     ` Geert Uytterhoeven
  2018-04-04  8:01       ` Pavel Machek
  0 siblings, 1 reply; 9+ messages in thread
From: Geert Uytterhoeven @ 2018-04-03  9:18 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Linus Torvalds, Linux Kernel Mailing List, linux-arch,
	James Hogan, David Howells, moderated list:PANASONIC MN10300...,
	Hirokazu Takata, Lennox Wu, Aaron Wu, Bryan Wu, Chris Metcalf,
	Jesper Nilsson

On Mon, Apr 2, 2018 at 9:54 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Apr 2, 2018 at 8:57 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> Regarding a possible revert, that would indeed involve reverting
> multiple patches for most architectures, plus parts of at least these
> three:
>
>   Documentation: arch-support: remove obsolete architectures
>   treewide: simplify Kconfig dependencies for removed archs
>   ktest: remove obsolete architectures
>
> For those, I went the other way, and removed all architectures at
> once to simplify my work and to avoid touching the same files up
> to eight times with interdependent patches (which couldn't
> be reverted without conflicts either).
>
> There are a couple of driver removal patches that got picked up
> into subsystem trees instead of this tree, so a full revert would also
> involve finding other drivers, but if you prefer to have the patches
> completely split up by arch, I could rework the series that way.

In reality, a resurrection may not be implemented as a pure revert, but as
the addition of a new architecture, implemented using modern features (DT,
CCF, ...).

Cfr. the resurrected arch/h8300, which doesn't have much in common with
the removed one:

$ git diff --stat v3.12..v4.2 -- arch/h8300
[...]
 197 files changed, 3155 insertions(+), 7849 deletions(-)

(for a total of ca. 6200 lines)

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [GIT PULL] arch: remove obsolete architecture ports
  2018-04-03  9:18     ` Geert Uytterhoeven
@ 2018-04-04  8:01       ` Pavel Machek
  2018-04-04  8:38         ` Arnd Bergmann
  0 siblings, 1 reply; 9+ messages in thread
From: Pavel Machek @ 2018-04-04  8:01 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Arnd Bergmann, Linus Torvalds, Linux Kernel Mailing List,
	linux-arch, James Hogan, David Howells,
	moderated list:PANASONIC MN10300...,
	Hirokazu Takata, Lennox Wu, Aaron Wu, Bryan Wu, Chris Metcalf,
	Jesper Nilsson

[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]

On Tue 2018-04-03 11:18:15, Geert Uytterhoeven wrote:
> On Mon, Apr 2, 2018 at 9:54 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Mon, Apr 2, 2018 at 8:57 PM, Linus Torvalds
> > <torvalds@linux-foundation.org> wrote:
> > Regarding a possible revert, that would indeed involve reverting
> > multiple patches for most architectures, plus parts of at least these
> > three:
> >
> >   Documentation: arch-support: remove obsolete architectures
> >   treewide: simplify Kconfig dependencies for removed archs
> >   ktest: remove obsolete architectures
> >
> > For those, I went the other way, and removed all architectures at
> > once to simplify my work and to avoid touching the same files up
> > to eight times with interdependent patches (which couldn't
> > be reverted without conflicts either).
> >
> > There are a couple of driver removal patches that got picked up
> > into subsystem trees instead of this tree, so a full revert would also
> > involve finding other drivers, but if you prefer to have the patches
> > completely split up by arch, I could rework the series that way.
> 
> In reality, a resurrection may not be implemented as a pure revert, but as
> the addition of a new architecture, implemented using modern features (DT,
> CCF, ...).

By insisting on new features instead of pure revert + incremental
updates, you pretty much make sure resurection will not be possible
:-(.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [GIT PULL] arch: remove obsolete architecture ports
  2018-04-04  8:01       ` Pavel Machek
@ 2018-04-04  8:38         ` Arnd Bergmann
  2018-04-04 13:28           ` James Hogan
  0 siblings, 1 reply; 9+ messages in thread
From: Arnd Bergmann @ 2018-04-04  8:38 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Geert Uytterhoeven, Linus Torvalds, Linux Kernel Mailing List,
	linux-arch, James Hogan, David Howells,
	moderated list:PANASONIC MN10300...,
	Hirokazu Takata, Lennox Wu, Aaron Wu, Bryan Wu, Chris Metcalf,
	Jesper Nilsson

On Wed, Apr 4, 2018 at 10:01 AM, Pavel Machek <pavel@ucw.cz> wrote:
> On Tue 2018-04-03 11:18:15, Geert Uytterhoeven wrote:

>> In reality, a resurrection may not be implemented as a pure revert, but as
>> the addition of a new architecture, implemented using modern features (DT,
>> CCF, ...).
>
> By insisting on new features instead of pure revert + incremental
> updates, you pretty much make sure resurection will not be possible
> :-(.

It wasn't that anybody demanded it to be that way, but rather that the
maintainer chose to do it like that, as you can see from the first version
that got posted: https://marc.info/?l=linux-arch&m=142181640803103
This is the only reference point we have, since no other architecture
ever got removed and then put back.

Also, now that the other architectures are gone, a lot of changes can
be done more easily that will be incompatible with a pure revert, so
the more time passes, the harder it will get to do that.

Some of the architectures (e.g. tile or cris) have been kept up to
date, but others had already bitrotted to the point where they were
unlikely to work on any real hardware for many relases, but a revert
could still be used as a starting point in theory.

      Arnd

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [GIT PULL] arch: remove obsolete architecture ports
  2018-04-04  8:38         ` Arnd Bergmann
@ 2018-04-04 13:28           ` James Hogan
  0 siblings, 0 replies; 9+ messages in thread
From: James Hogan @ 2018-04-04 13:28 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Pavel Machek, Geert Uytterhoeven, Linus Torvalds,
	Linux Kernel Mailing List, linux-arch, David Howells,
	moderated list:PANASONIC MN10300...,
	Hirokazu Takata, Lennox Wu, Aaron Wu, Bryan Wu, Chris Metcalf,
	Jesper Nilsson

[-- Attachment #1: Type: text/plain, Size: 736 bytes --]

On Wed, Apr 04, 2018 at 10:38:41AM +0200, Arnd Bergmann wrote:
> Also, now that the other architectures are gone, a lot of changes can
> be done more easily that will be incompatible with a pure revert, so
> the more time passes, the harder it will get to do that.

Yes, and an out-of-tree arch port (as effectively these arches now are)
requires constant maintenance (often subtle runtime breakage) to keep up
to date with each new kernel release, which happens mostly automatically
from arch maintainer POV while they're merged.

Even without changes intentionally taking advantage of not having to
care about these arches, it'll be only a few cycles at the most before a
plain revert won't "just work".

Cheers
James

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2018-04-04 13:28 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-04-02  7:17 [GIT PULL] arch: remove obsolete architecture ports Arnd Bergmann
2018-04-02 18:57 ` Linus Torvalds
2018-04-02 19:54   ` Arnd Bergmann
2018-04-03  9:18     ` Geert Uytterhoeven
2018-04-04  8:01       ` Pavel Machek
2018-04-04  8:38         ` Arnd Bergmann
2018-04-04 13:28           ` James Hogan
2018-04-03  2:57 ` Palmer Dabbelt
2018-04-03  4:08 ` Linus Torvalds

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.