[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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[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
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.
