On Fri, 2020-10-16 at 08:30 -0700, 洛佳 Luo Jia wrote:
As we very glad to acknowledge, RISC-V's SBI standard now have a list
of implementations, such as BBL,
OpenSBI, Xvisitor and KVM. To expand the list in the Specification,
we are now to introduce RustSBI.
RustSBI is a minimal SBI implementation in Rust, a programming
language focused in performance,
reliability and productivity. We use this language other than C, is
to explore the ability to use SBI
standard in a wider choice of languages. SBI from both supervisor
side and machine side is a special
convention of binary interface, we could expand the standard from one
specific programming language
to a wider use.
The project RustSBI is not only in theory, but have tested in
machines and boards.
We have tested RustSBI on real K210 boards and QEMU emulator on
operating system workshops (a tutorial for example).
K210 uses 1.9.1 version of RISC-V privileged standard, other than
1.11 that we use now.
It has some differences between then and now, for example there
wasn't a S-level external interrupt and so on.
We are working to implement some features to make it all compatible
to unified SBI standard.
To accomplish in this way, RustSBI should implement another function
in its own module or function,
to work for compability with wider SoC and emulators. If we have our
own Implementation ID, we may write
the above functions in Firmware Code Base Specific extension space to
be compatible to SBI standard.
Or there are maybe more solutions to these problems.
We propose to add RustSBI to list 'SBI Implementation IDs'. By now it
has ID number 0 to 3 for four different
SBI implementations. If that's possible and acceptable, we would like
to take the ID number 4 for RustSBI.
We'll be very glad to discuss about this problem, or to see that ID
assignment to RustSBI is granted.
Looks good to me. I don't see a reviewed-by tag as this is not actual
patch. I have approved the PR in github.https://github.com/riscv/riscv-sbi-doc/pull/61
For future reference, it is preferred that every patch should be sent
to the mailing list first as there a wider audience that participate in
the mailing list discussions compared to github PRs.