On Mon, 22 May 2017 18:16:20 PDT (-0700), o...@lixom.net wrote: > Hi Palmer, > > On Mon, May 22, 2017 at 5:41 PM, Palmer Dabbelt <pal...@dabbelt.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!
