From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760677AbdEWBQZ (ORCPT ); Mon, 22 May 2017 21:16:25 -0400 Received: from mail-ua0-f180.google.com ([209.85.217.180]:34104 "EHLO mail-ua0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757760AbdEWBQW (ORCPT ); Mon, 22 May 2017 21:16:22 -0400 MIME-Version: 1.0 X-Originating-IP: [209.133.79.5] In-Reply-To: <20170523004107.536-1-palmer@dabbelt.com> References: <20170523004107.536-1-palmer@dabbelt.com> From: Olof Johansson Date: Mon, 22 May 2017 18:16:20 -0700 Message-ID: Subject: Re: RISC-V Linux Port v1 To: Palmer Dabbelt Cc: "linux-kernel@vger.kernel.org" , Arnd Bergmann , albert@sifive.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Palmer, On Mon, May 22, 2017 at 5:41 PM, Palmer Dabbelt 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