SUPERH platform development
 help / color / mirror / Atom feed
From: Rich Felker <dalias@libc.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
	Adam Borowski <kilobyte@angband.pl>,
	Christoph Hellwig <hch@lst.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Linux-sh list <linux-sh@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] remove arch/sh?
Date: Tue, 25 Jun 2019 14:28:32 +0000	[thread overview]
Message-ID: <20190625142832.GD1506@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAK8P3a3irwwwCQ_kPh5BTg-jGGbJOj=3fhVrTDBUZgH1V7bpFQ@mail.gmail.com>

On Tue, Jun 25, 2019 at 02:50:01PM +0200, Arnd Bergmann wrote:
> On Tue, Jun 25, 2019 at 2:02 PM John Paul Adrian Glaubitz
> <glaubitz@physik.fu-berlin.de> wrote:
> >
> > Adam,
> >
> > On 6/25/19 1:21 PM, Adam Borowski wrote:
> > >> We're still using sh4 in Debian
> > >
> > > I wouldn't call it "used": it has popcon of 1, and despite watching many
> > > Debian channels, I don't recall hearing a word about sh4 in quite a while.
> >
> > So, according to your logic, Debian should drop the mips64el (popcon 1)
> > and riscv64 ports (popcon 2) [1]?
> >
> > > Hardware development is dead: we were promised modern silicon by j-core
> > > after original patents expired, but after J2 nothing happened, there was
> > > silence from their side, and now https://j-core.org is down.
> >
> > It's not dead. You can still run it on an FPGA, the code is freely available.
> > Plus, the architecture seems to be still in use in the industry [2].
> 
> It would be nice if one of the maintainers or the remaining users could go
> through the code though and figure out which bits are definitely dead
> (e.g. sh5),

I'm in favor of removing sh5 (64-bit). It's already been removed from
GCC and as I understand there was never any hardware really available.
There's also a lot of NUMA-type infrastructure in arch/sh that looks
like YAGNI violations -- no clear indication that there is or ever was
any hardware it made sense on. That could probably be removed too.

> don't build, or are incomplete and not worked on for a long
> time, compared to the bits that are known to work and that someone
> is still using or at least playing with.
> I guess a lot of the SoCs that have no board support other than
> the Hitachi/Renesas reference platform can go away too, as any products
> based on those boards have long stopped updating their kernels.

My intent here was always, after getting device tree theoretically
working for some reasonable subset of socs/boards, drop the rest and
add them back as dts files (possibly plus some small drivers) only if
there's demand/complaint about regression.

Rich

  reply	other threads:[~2019-06-25 14:28 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-25  8:56 [RFC] remove arch/sh? Christoph Hellwig
2019-06-25  9:02 ` John Paul Adrian Glaubitz
2019-06-25 11:21   ` Adam Borowski
2019-06-25 12:02     ` John Paul Adrian Glaubitz
2019-06-25 12:50       ` Arnd Bergmann
2019-06-25 14:28         ` Rich Felker [this message]
2019-06-25 15:48           ` Arnd Bergmann
2019-06-26 11:25             ` Yoshinori Sato
2019-06-26 15:38               ` Rich Felker
2019-06-26 15:56                 ` John Paul Adrian Glaubitz
2019-07-05 13:51                 ` Yoshinori Sato
2019-07-05 14:04                   ` John Paul Adrian Glaubitz
2019-07-05 15:14                   ` Rich Felker
2019-06-25 14:21   ` Rich Felker
2019-06-25 14:23     ` Christoph Hellwig
2019-06-25 14:29       ` Rich Felker
2019-06-25 14:31         ` John Paul Adrian Glaubitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190625142832.GD1506@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=arnd@arndb.de \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=hch@lst.de \
    --cc=kilobyte@angband.pl \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=ysato@users.sourceforge.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox