linux-kernel - Re: RISC-V Linux Port v1

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: <20170523064534.GG3447@distanz.ch>
Date:   Tue, 23 May 2017 08:45:34 +0200
From:   Tobias Klauser <tklauser@...tanz.ch>
To:     Palmer Dabbelt <palmer@...belt.com>
Cc:     olof@...om.net, linux-kernel@...r.kernel.org,
        Arnd Bergmann <arnd@...db.de>, albert@...ive.com
Subject: Re: RISC-V Linux Port v1

Hi Palmer,

On 2017-05-23 at 05:36:55 +0200, Palmer Dabbelt <palmer@...belt.com> wrote:
> On Mon, 22 May 2017 18:16:20 PDT (-0700), olof@...om.net wrote:
> > On Mon, May 22, 2017 at 5:41 PM, Palmer Dabbelt <palmer@...belt.com> wrote:
> >> We'd like to submit for inclusion in Linux a port for the RISC-V architecture.
> >> While it is doubtlessly not complete, we think it is far enough along to start
> >> the upstreaming process.  Our binutils and GCC ports have been accepted and
> >> released, and we plan on submitting glibc patches soon.
> >>
> >> This port targets Version 1.10 of the RISC-V Privileged ISA, and supports both
> >> the RV32 and RV64 user ISAs.  The RISC-V community and the 60-some member
> >> companies of the RISC-V Foundation are quite eager to have a single, standard
> >> Linux port.  We thank you in advance for your help in this process and for your
> >> feedback on the software contribution itself.
> >>
> >> These patches build and boot on top of 4.12-rc2.  I understand that the merge
> >> window is closed, but it was suggested that the best time to submit a new
> >> architecture port would be right after an RC2 as the earliest point at which
> >> the tree is usually generally churn-free enough.  While we optimistically hope
> >> that we can get the port in for the 4.13 merge window, we're also eager to
> >> ensure that the user-visible ABI is sane so we can proceed with our glibc port.
> >> We'd like to at least get any user ABI issues shaken out as soon as possible,
> >> even if we don't make it into 4.13.

[...]

> > I'll add more comments on some of the individual patches; expect this
> > review to take a little while. Reposting once or twice a week to show
> > incorporated changes can be useful; more than that and it can be
> > harder to follow along in the discussion. It all depends on how much
> > comments you end up receiving.
> 
> OK.  I'll incorporate all the feedback I get over the next week or so into a v2
> patch set.

You might want to Cc linux-arch@...r.kernel.org on future iterations of
this patchset where there's less "noise" than on LKML and the relevant
people are more likely to notice ;) Likewise, the device-tree specific
bits (e.g.  the bindings documentation) should probably be Cc'ed to
devicetree@...r.kernel.org

Tobias