linux-kernel - Re: [RFC] remove arch/sh?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 25 Jun 2019 10:28:32 -0400
From:   Rich Felker <dalias@...c.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
        Adam Borowski <kilobyte@...band.pl>,
        Christoph Hellwig <hch@....de>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        Linux-sh list <linux-sh@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] remove arch/sh?

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@...sik.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