Procedure for submitting RISC-V based BSP to Newlib
Jim Wilson
jimw@sifive.com
Wed Jul 24 21:40:00 GMT 2019
On Wed, Jul 24, 2019 at 9:20 AM Kito Cheng <kito.cheng@gmail.com> 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
More information about the Newlib
mailing list