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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20190625142144.GC1506@brightrain.aerifal.cx>
Date:   Tue, 25 Jun 2019 10:21:44 -0400
From:   Rich Felker <dalias@...c.org>
To:     John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>
Cc:     Christoph Hellwig <hch@....de>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        Arnd Bergmann <arnd@...db.de>, linux-sh@...r.kernel.org,
        linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] remove arch/sh?

On Tue, Jun 25, 2019 at 11:02:36AM +0200, John Paul Adrian Glaubitz wrote:
> Hi Christoph!
> 
> On 6/25/19 10:56 AM, Christoph Hellwig wrote:
> > arch/sh seems pretty much unmaintained these days.  The last time I got
> > any reply to sh patches from the list maintainers, and the last maintainer
> > pull request was over a year ago, and even that has been rather sporadic.
> > 
> > In the meantime we've not really seen any updates for new kernel features
> > and code seems to be bitrotting.
> 
> We're still using sh4 in Debian and most of the stuff works fine. There is
> one patch by Michael Karcher that fixes a bug in the kprobes code that someone
> should pull in as it unbreaks the kernel with kprobes enabled [1].
> 
> Yoshinori Sato is still active sporadically and has a kernel tree here
> where he collects patches for -next [2].
> 
> Otherwise, the kernel works fine.

Seconded. I apologize that I haven't been active in maintaining the
tree as well; funding for time working on it dried up quite a while
back and I'm stretched rather thin.

I'm generally okay with all proposed non-functional changes that come
up that are just eliminating arch-specific cruft to use new shared
kernel infrastructure. I recall replying to a few indicating this, but
I missed a lot more. If it would be helpful I think I can commit to
doing at least this more consistently, but I'm happy to have other
maintainers make that call too.

I do still have WIP forward-ports of Yoshinori Sato's device tree
patches from attempts to get them working on Landisk; they're sitting
in my working tree, but the PCI stuff isn't working, probably due to
changes out from under it. I'd like to work together on getting that
fixed to unblock me on something I'm interested in getting working on
my own time, but we've never managed to sync up on it.

As Adrian probably remembers, there's also the forked-tree, bitrotted
STlinux stuff I want to get merged back into mainline based on device
tree once it's there (doing it now doesn't make sense, as it would
just add a ton more board-file cruft where it's slated for removal).
This would improve the future viability of the arch/platform since,
currently, I think ST's chips are the main SH ones you can find/get --
for example in the nextvod devices.

Rich