lkml.org 
[lkml]   [2019]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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@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

\
 
 \ /
  Last update: 2019-06-25 16:29    [W:0.044 / U:1.328 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site