
Writing a RISC-V OS in Rust: System Calls - azhenley
http://osblog.stephenmarz.com/ch7.html
======
MisterTea
For inspiration, have a look at the plan 9 syscall table:

[http://aiju.de/plan_9/plan9-syscalls](http://aiju.de/plan_9/plan9-syscalls)

This is how you make a simple yet flexible OS. Use an rpc protocol to do all
the talking to objects within the system which are exposed as files. It's very
REST like and allows any programming language to interact with those objects
by reading/writing them as files. So you have a very uniform interface that
eliminates a lot of binaries as now simple scripts can handle the work of
reading and writing those files. Then realize that you can easily export those
files to other machines on a lan or the internet. So the tcp stack of an
internet facing machine can be exported and mounted on multiple machines who
now all talk to the internet via that one machines tcp stack. And that can
even be done across the net to bypass "great firewalls". Bye bye nat.

~~~
zozbot234
> Use an rpc protocol to do all the talking to objects within the system which
> are exposed as files.

At some point, you're just adding pointless layers of indirection by doing
this. NT tried this approach, and it is anything but "simple".

You can do _many_ things quite naturally by interacting with bytestream-like
or block-like objects that are exposed via some sort of hierarchical namespace
("files"), but this doesn't really cover _everything_. Some things may be
better done, even in a script, by interacting with a "binary" that in turn
just wraps a binary library exposing some kind of ABI.

~~~
kjs3
I don't disagree, per se, but designing for the exception is also a good way
to end up with a mess. You have to carefully measure the impact (performance,
maintenance, developer impact, etc.) of every special case.

------
bogomipz
>"Each mode has a different ecall cause. If we make an ecall in machine mode
(the most privileged mode), we get cause #11. Otherwise, if we make an ecall
in supervisor mode (typically the kernel mode), we get cause #9."

Could someone say if the kernel runs in Supervisor mode what is the intention
of machine mode in RISC-V?

~~~
monocasa
Stuff like "this board/chip needs real time response in order to not melt
itself despite not being able to trust that the OS is hard real time" like
System Management Mode was originally intended.

It's also been handy for trying out supervisor mode concepts and adding
software based support on chips that don't support all the features like
hypervisor extensions.

~~~
andrekandre
right, afaiui basically you can trap on unimplemented instructions and emulate
risc-v extensions without hardware support (very cool imho)

this short video explained it well (to me anyways):
[https://www.youtube.com/watch?v=4JIvnWEs_pA](https://www.youtube.com/watch?v=4JIvnWEs_pA)

(hypervisor trap explanation at 11m20s mark)

------
Koshkin
I just wonder what chances any new general-purpose OS kernel may have against
Linux.

~~~
beisner
I suspect that whatever replaces Linux will probably involve a paradigm shift
at the lowest level. Perhaps capability-based IPC, perhaps seamlessly
integrating local and networked nodes, etc. It’s going to take major major
improvements to move the world off of the Linux kernel.

~~~
monocasa
I imagine it's going to be an exokernel that can run pretty arbitrary user
lands as if they were containers, built on cap based security.

If anyone agrees with me and wants to help out making that happen on an open
source code base, hit me up.

~~~
dnautics
I don't have time to work on this, but I highly recommend looking at using the
erlang Virtual machine as your exokernel environment.

~~~
SkyMarshal
Why BEAM? I know it’s good, just curious why this specific use case.

