Re: Procedure for submitting RISC-V based BSP to Newlib

On Wed, Jul 24, 2019 at 9:20 AM Kito Cheng <[email protected]> wrote:
> riscv-newlib in riscv-gnu-toolchain basically won't modify anything if
> possible, it just kind of buffer, hold some un-upstreamed patches, and
> will going to upstream eventually, it's also a place to report RISC-V
> specific bug.

I would prefer no un-upstreamed patches at all in riscv-newlib.
Currently I think we don't have any.  We just have some patches
backported.  This is something that could just as well be handled as a
RISC-V Foundation vendor branch in the upstream tree.  The only issue
is getting upstream write access for everyone that wants to
contribute.  Some people got write access to the github.com/riscv
trees long ago before tools were upstreamed, and have been reluctant
to get write access to the upstream trees.  I've been acting as a go
between for some of this, but eventually I would like to see the
riscv-newlib and other riscv toolchain trees die off and have us do
all work upstream.  But for the moment, the fact that the 32-bit glibc
support isn't upstream yet means we have to have riscv specific
toolchain sources to hold those patches, so I can't kill off the
github.com/riscv toolchain trees just yet.  I am slowly moving in that
direction though.  I just recently replaced riscv-qemu with upstream
qemu after getting a few patches accepted into upstream qemu.  I'd
like to do this for a few more riscv trees when I have a chance.

> So the newlib part I think you could submit patches to this mailing
> list directly or send a pull request on riscv-newlib is fine.
> And riscv-gnu-toolchain part you could try to fork it first, and might
> send pull request on gitthub to start further discussion about how to
> integration.

Since these filesystem patches aren't riscv specific,  they need to go
upstream first.  It isn't reasonable to ask us to be a go-between for
patches like this.  Once they are upstream, we can backport them if
necessary and/or convenient.

Jim