Date: Wed, 1 Apr 2020 09:40:01 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: 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, which > could be synthesized and "burnt" to a Lattice ECP5-5G Versa Evaluation > Board with completely FOSS toolchain without any closed source > component.  > > 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.