From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 26139 invoked from network); 1 Apr 2020 13:40:17 -0000 Received-SPF: pass (mother.openwall.net: domain of lists.openwall.com designates 195.42.179.200 as permitted sender) receiver=inbox.vuxu.org; client-ip=195.42.179.200 envelope-from= Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with UTF8ESMTPZ; 1 Apr 2020 13:40:17 -0000 Received: (qmail 19766 invoked by uid 550); 1 Apr 2020 13:40:14 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 19745 invoked from network); 1 Apr 2020 13:40:13 -0000 Date: Wed, 1 Apr 2020 09:40:01 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200401134001.GY11469@brightrain.aerifal.cx> References: <20200401061825.GA6733@APC301.andestech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200401061825.GA6733@APC301.andestech.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] About "stable ABI" for riscv32 kernel issue and Alpine port On Wed, Apr 01, 2020 at 02:18:27PM +0800, Ruinland ChuanTzu Tsai wrote: > Hi Rich and All, > > Back in 13th Mar, Rich has stated that "kernel has not declared it > (RV32 Linux) a stable ABI yet." I'm wondering whether Rich could kindly > elaborate a little bit more details about this concern ? I don't know the official statement of kernel policy, but my understanding of it is just that the normal kernel stability policy (that they can't "break userspace", including changing type definitions that are part of user-kernel ABI, removing syscalls, etc.) doesn't apply yet for RV32. I'd welcome a clarification from anyone who can provide one on whether this is still the case, and if so, what needs to happen to get past that. > Since my employer, Andes Tech, is one of the founding plantium memeber > of RISC-V Foundation and we're shipping a considerable amount of > Linux-running RV32 products at the time we're speaking, we will be > happy to help on the kernel side and make it more stablized and secured. It's not a matter of secure or "stable" in the sense of not crashing. It's a matter of "stable" in the sense of "not changing out from under you". > During my pastime, I've ported Alpine Linux with musl 1.2.0 to a > publicily available and open-sourced platform, LiteX/VexRiscv[1], which > could be synthesized and "burnt" to a Lattice ECP5-5G Versa Evaluation > Board with completely FOSS toolchain without any closed source > component. [2] > > And here's the footage of booting : > https://asciinema.org/a/315205 > > Unfortunately, since my musl 1.2.0 is an inhouse work and we are still > polishing and preparing it for upstreaming, please excuse me from not > releasing the cpio image and stuffs at this time being. > > P.S. > Regarding the last mail: > https://www.openwall.com/lists/musl/2020/03/13/4 > I'm not really qualified to answer the reason/profit of lacking LR/SC > pair. Yet just a rough hunch that LR/SC is much stronger in atomicity > than other AMOs. Yes, LR/SC is a slightly stronger primitive in some sense, but at the same time it's far easier to fake an implementation on single-core designs. In any case if there are chips people want to run Linux/musl on that lack LR/SC then we need to know what the intended way to get atomics is. Does kernel trap and emulate? Do we have to make a syscall? Is there a function kernel exports to userspace like kuser_helper on pre-v6 ARM that establishes a contract of cooperation between kernel and userspace to restart interrupted atomics? What are you doing with your WIP port? Rich