Message-ID: <CAOesGMh5cQhUo6vJP_t87GdX5yN+OS5Jsvn8h2=t-G2binVc-Q@mail.gmail.com>
Date:   Mon, 22 May 2017 18:16:20 -0700
From:   Olof Johansson <olof@...om.net>
To:     Palmer Dabbelt <palmer@...belt.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>, albert@...ive.com
Subject: Re: RISC-V Linux Port v1

Hi Palmer,

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.

Time is right for review and eventual merge of this. Whether it makes
4.13 depends on how much discussion ensues. :)

> Albert and I will volunteer to maintain this port if it's OK with everyone.

It always makes sense to have architecture-knowledge people maintain
it; no complaints from me.

What we've seen been useful on other platforms (i.e. arm/arm64) is to
offload the per-vendor stuff to a separate tree. It might or might not
be needed here; likely to start out it won't be enough material to
need it.

> We'd like to thank the various members of the RISC-V software community who
> have helped us with the port.
>
> Thanks!
>
> In addition to the threaded messages, our port can be found on Git Hib
>
>   https://github.com/riscv/riscv-linux/tree/riscv-for-submission-v1
>
> [PATCH 1/7] RISC-V: Top-Level Makefile for riscv{32,64}
> [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs
> [PATCH 3/7] RISC-V: Device Tree Documentation
> [PATCH 4/7] RISC-V: arch/riscv/include
> [PATCH 5/7] RISC-V: arch/riscv/lib
> [PATCH 6/7] RISC-V: arch/riscv/kernel
> [PATCH 7/7] RISC-V: arch/riscv/mm

So, one overall comment on this patchset is that it's not bisectable
(i.e. early patches add Makefile contents that refers to directories
not yet introduced).

While it's not overly important to really split up a new architecture
introduction into small incremental patches, we generally strive to
have the tree fully buildable at any given commit. Some minor
rearranging would alleviate these problems.

Also, none of the patches seem to have any descriptions. Adding some
high-level descriptions of what's in each patch in the patch itself is
useful both for reviewing now, and for educating anyone coming along
later on trying to learn about the code and why it's been implemented
as it has.

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.


-Olof

Powered by blists - more mailing lists