From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85871 invoked by alias); 24 Jul 2019 21:40:18 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 85862 invoked by uid 89); 24 Jul 2019 21:40:18 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=slowly, H*f:sk:yXCZAV0, H*i:sk:yXCZAV0 X-HELO: mail-vs1-f45.google.com Received: from mail-vs1-f45.google.com (HELO mail-vs1-f45.google.com) (209.85.217.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 24 Jul 2019 21:40:16 +0000 Received: by mail-vs1-f45.google.com with SMTP id u3so32334218vsh.6 for ; Wed, 24 Jul 2019 14:40:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0AnFPeT8/9I40Pt2chnbFLBJ7W83ez8nRXz+6rMqhv4=; b=DWvrlVdw+ak5YDpaj70k4TMs5xafKS3m2JrWrCcsWOa/9JkrvHOt5GZ3Asnl5IQPMI EzV4JdvNGBXMK6MACukQ9erbg3F7rDW1OlBEn3ZSreFFygZCr60I2uLRGhfZPc6UbWDH Qc/Ofuwa5duLBVxQBeaQuQdXRTNeBJqtD48jGSf8LrQQtF8QU+8KbHR5PceuA5BKmN27 qLbow9qsQvJZuxSJo49/bS0wg6zbBWL76D+GZq79uUV9Q469WA0YzMDz/v+hPZB9j120 ze+OAg50B+U0N8ri6xftaO3cwRzxjemgtvuJ6NYvKv7C41buaqqFRCD3feksC2co0OBU QMew== MIME-Version: 1.0 References: In-Reply-To: From: Jim Wilson Date: Wed, 24 Jul 2019 21:40:00 -0000 Message-ID: Subject: Re: Procedure for submitting RISC-V based BSP to Newlib To: Kito Cheng Cc: "Prof. Michael Taylor" , Newlib , Bandhav Veluri , Bandhav Veluri , Palmer Dabbelt Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019/txt/msg00347.txt.bz2 On Wed, Jul 24, 2019 at 9:20 AM Kito Cheng 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