Message-ID: <mhng-2403f8af-38d0-496f-9688-931095346ee7@palmer-si-x1c4>
Date:   Mon, 22 May 2017 20:36:55 -0700 (PDT)
From:   Palmer Dabbelt <palmer@...belt.com>
To:     olof@...om.net
CC:     albert@...ive.com
Subject:     Re: RISC-V Linux Port v1

On Mon, 22 May 2017 18:16:20 PDT (-0700), olof@...om.net wrote:
> 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.

I'm OK with that.  We've been using http://github.com/riscv to hold all our
other "riscv-next" branches, but if you think another place is more appropriate
then I'm OK with that as well.

>> 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.

I only really split things up so they'll get through the various mailing lists,
I think of this as one logical commit so I didn't really worry about ordering.
I'll swizzle them around next time so everything always builds.

> 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 guess I just wasn't really sure what to say in the big code dumps.  I'll look
through and try to come up with something better for next time.

>
> 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.

Thanks!

Powered by blists - more mailing lists