Date 1 - 2 of 2
[Software] Propose to add RustSBI into 'SBI Implementation IDs' list
洛佳 Luo Jia
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.
On Fri, 2020-10-16 at 08:30 -0700, 洛佳 Luo Jia wrote:
Hello All,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.
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.
|1 - 2 of 2|