
Real hardware breakthroughs, and focusing on rustc - est31
https://www.redox-os.org/news/focusing-on-rustc/
======
rvz
> With Redox OS being a microkernel, it is possible that even the driver level
> could be recompiled and respawned without downtime, making it incredibly
> fast to develop for.

Honestly, I am always excited about systems like Redox that are going for the
integrated and consistent user experience approach into building OSes. The
microkernel approach on modern hardware sounds interesting here given that
they skipped 32 bit entirely. The impression of most developers here keep
referencing the Tanenbaum-Torvalds debate of 1992, as a justification for
adopting monolithic kernels, which made sense at the time.

Fast forward into 2019, given that the CPU-level vulnerabilities are now
alight, the need for a microkernel OS written in Rust could not have been
greater. The reasons against a microkernel was commonly associated with the
IPC and 'context-switch' performance impacts, but I find that the security
implications here can help with countering these CPU-level vulnerabilities and
the performance-concerns are in-directly solved by hardware
advancements/implementations given for free or optimising the OS to run on
multi-core systems.

Systems like Fuchsia have done both and I hope Redox follows and does this
too.

~~~
amluto
I’m not sure I understand what you’re talking about. All the ugly CPU
vulnerabilities make context switching very, very slow. A microkernel needs to
contest switch more than a monolithic kernel, and the overhead keeps
increasing.

~~~
rvz
> All the ugly CPU vulnerabilities make context switching very, very slow. A
> microkernel needs to contest switch more than a monolithic kernel, and the
> overhead keeps increasing.

In the case of the Zircon microkernel in Fuchsia, unlike Linux, almost all
system-calls are asynchronous/non-blocking with a small number that are
blocking [0], which is interesting since the OS is also fundamentally
optimised for multi-core systems. Combined with both features, it makes it
very suitable for real-time based applications, something that Linux is not
optimised for and requires fundamental tweaking and changes for Linux or even
some other traditional microkernels to achieve.

Thus, I doubt that on a system like Fuchsia/Zircon, the context switch would
be notably 'very, very slow', even if Fuchsia was running on modern-hardware
optimised for microkernels such as Zircon if that were to happen.

[0]
[https://fuchsia.googlesource.com/fuchsia/+/refs/heads/master...](https://fuchsia.googlesource.com/fuchsia/+/refs/heads/master/docs/concepts/kernel/README.md)

~~~
chc4
Reading around, Zircon syscalls are non-blocking at the scheduler level. Each
syscall still requires a full context switch into kernel mode, though.

They can probably do some smart stuff with having each syscall just add stuff
to a work queue so userspace can resume as quickly as possible, but it's still
fundamentally more context switches than e.g. Linux would have, which if side-
channel attacks keep coming out might be a problem for them.

~~~
yabadabadoes
My impression on systems from the days before linux/Intel began having real
SMP is that if you are willing to go off the rails completely on supporting
1-2 core machines and making every CPU available to every task, then blocking
side channel attacks no longer requires all the work..

If mitigation is starting to amount to ~20%, that's roughly a CPU and soon to
be 2-3, that can be told to never process directly for Userland and never tell
Userland when exactly output queue contents of sensitive tasks become
available. All that work essentially being free compared to running with
Intel's fixes and full CPU flexibility.

------
ChuckMcM
It is an interesting discussion, I'm excited to see a full OS in Rust,
something I was unsuccessful in achieving with Java[1].

On the performance question, I have a new 64 bit system coming with 64
threads[2], and I'm really curious to experiment with non-relocating
microkernel architectures (architectures where kernel features have a fixed
address that doesn't change while running). This is something I dreamed about
at Sun using a Dragon (64 thread SPARC machine) and Spring (the research OS)
but it was too expensive to allocate one of those machines to our small group
for OS research.

[1] Yes, there are OSes written (mostly) in Java, but at Sun we tried a
completely Java OS and the safety features of the language prevented it. The
'controlled relaxation' of safety features in Rust here (as opposed to 'jump
into native code, all bets are off!') are awesome.

[2] In theory I'm in the queue for the first arrival of an AMD TR-3990 for my
sTRX motherboard. We'll see how that holds up. :-)

~~~
OJFord
How do you have a 'completely Java OS' (even conceptually) - you need
something for a JVM to run on?

~~~
ChuckMcM
The working theory was the JVM was just a machine specification, which could,
if you wanted, be implemented as an immutable processor (either a chip or a
set of chips).

So if you can write a multi-user OS that only used the JVM (so it was 'Java
all the way down') then you could build a Java chip for embedded systems, use
a JVM for running it on a commodity processor, etc.

I had a lot of fun building the PiDP11/70 kit last year which is a PDP 11/70
built on top of simh on a Raspberry Pi. You can run BSD 2.1 on it which is
decidedly Old School, but it (and RSX-11M+) are classical multi-user OSes. And
that system has all the pieces of what we were trying to do with Java which is
a virtual machine, compilers that converted code to run on that virtual
machine, and an Operating system that can be compiled to run on it.

------
chubs
Congrats jeremy, looks fantastic! That video showing the miniscule boot time
brings me hope that it is possible to write software that takes advantage of
the crazy-fast computers we have these days.

------
Animats
Why was rustc modified to require dynamically linked libraries at compile
time? That seems a strange feature for a compiler.

~~~
est31
LLVM is (at least currently) being dynamically linked to allow shipping
multiple copies of LLVM (one for emscripten, one for everything else) without
having to ship multiple entire compilers. Now that emscripten uses LLVM's
built in wasm backend it's not needed any more, but currently support is still
in the compiler. This is a PR to remove it: [https://github.com/rust-
lang/rust/pull/65703](https://github.com/rust-lang/rust/pull/65703)

~~~
mmastrac
I wonder if Bitcode support in Rust will result in this dynamic linking being
required again.

~~~
est31
I've been wondering about the same actually. bitcode likely needs swift's LLVM
or another apple provided LLVM fork and you'd probably want to link
dynamically. I guess they are not intending to offer compilation to bitcode
any time soon.

