
Writing an OS in Rust: Hardware Interrupts - ingve
https://os.phil-opp.com/hardware-interrupts/
======
__exit__
Nice to see this series continued! I wish there were more, potentially non-
discontinued series or books on how to build actual projects with Rust from
scratch.

~~~
steveklabnik
Each of the four domain working groups this year has been working on some sort
of "build a project" book:

* CLIs: [https://rust-lang-nursery.github.io/cli-wg/](https://rust-lang-nursery.github.io/cli-wg/)

* WASM: [https://rustwasm.github.io/book/](https://rustwasm.github.io/book/)

* Network services: [https://aturon.github.io/apr/](https://aturon.github.io/apr/)

* Embedded: [https://rust-embedded.github.io/book/](https://rust-embedded.github.io/book/)

They're all at various states of completion at the moment.

~~~
monocasa
Where does the embedded wg coordinate? I'm giving a talk tomorrow on a post
mortem on porting rust to a new embedded target (the Nintendo 64).

~~~
jamesmunns
Hey, member of the embedded wg here.

Originally, our first push was to get Cortex M bare metal microcontrollers as
a "Tier 1" stable target for the 2018 edition of Rust.

Over the last couple months, we've been expanding, and have subteams for a
bunch of different topics, including chip support, drivers, documentation,
tooling, etc. We're mostly focused on helping other people who are getting
started with embedded rust, as well as give feedback to the compiler teams,
etc.

It would be interesting to hear more about your porting attempt, we also have
a blog - [https://rust-embedded.github.io/blog/](https://rust-
embedded.github.io/blog/) \- if you'd like to share it as a blog post.

As Steve mentioned, [https://github.com/rust-
embedded/wg](https://github.com/rust-embedded/wg) is our main coordination
repo, and has links to most of the stuff we're actively working on.

------
d33
Just wanted to say that I wish that this was how kernels were made - out of
modular, reusable blocks. Would this scale? In other words, could Redox and
the OS described in the system share IRQ code from the same crate and
ultimately grow into two different systems that are built of mostly the same
crates for low-level stuff, just wired differently?

~~~
DoritoChef
From the historical point of view, this heavy decoupling is associated with
microkernels which fell out of favor with the rise of the Linux kernel. I
think in this day and age, modern programming languages could make building a
microkernel that doesn't fall prey to the shortcomings of MINIX a possibility.

~~~
d33
Microkernels are IPC-heavy, right? What I rather imagine is having modules at
source level, not kernel level. So the thing still compiles down to a
monolith/hybrid, but modules are abstracted away and reusable.

~~~
fooker
Source level modules sound awesome. Would need a high level language though.

~~~
nicoburns
Like Rust?

~~~
fooker
Maybe, I would personally go with C++.

------
ajross
All of the effort expended to enable the legacy PIC so that the legacy PIT
doesn't fire timer interrupts into an invalid configuration seems weird,
especially when justified with "the APIC is too complicated and we'll show
that later".

Um... the Local APIC interface needed to catch an interrupt and wire up the
timer is if anything simpler than what is presented here.

~~~
davemp
I'm with you on this. It's similar to how every x86_64 OS guide goes through
the ancient ritual of working your way up to long mode. Why not just use UEFI?

~~~
ajross
Well... the hardware gets in your way there. Long mode properly requires
paging to be enabled, which means that you have the choice between a
complicated hardware bootstrapping proceedure to enable it, or a complicated
bootloader environment which has already grabbed and used chunks of memory for
page tables you need to not step on.

Also, use of real mode (still required for BIOS calls like e820) requires the
ability to get back _out_ of real mode, so you need the bootstrapping stuff in
a real OS even if it's not in the tutorial.

But the register poking in the PIC/PIT is just silly. Turn that stuff off and
use the correct hardware, even in a tutorial. Unless it's a tutorial on PC
architecture history, I guess.

~~~
davemp
> ...use of real mode (still required for BIOS calls like e820) requires the
> ability to get back out of real mode, so you need the bootstrapping stuff in
> a real OS even if it's not in the tutorial.

I'm not particularly well versed in UEFI/BIOS features, but shouldn't BIOS
calls like e820 be avoided in favor of equivalent UEFI functions?

> the hardware gets in your way there. Long mode properly requires paging to
> be enabled, which means that you have the choice between a complicated
> hardware bootstrapping proceedure to enable it, or a complicated bootloader
> environment which has already grabbed and used chunks of memory for page
> tables you need to not step on.

Just figuring out the UEFI's page-table structure seems much less burdensome
to me. You'd have to set the tables up yourself regardless. Is the
documentation/environment really so poor as to make just doing it yourself
easier?

In theory you should just be able to include a header or use a crate (a cousin
comment linked one) and not have to write any assembly.

~~~
ajross
> shouldn't BIOS calls like e820 be avoided in favor of equivalent UEFI
> functions?

Should, but can't, because they don't work in general. Windows and Linux get
their memory map from e820, so that's all the system vendors test.

------
mapcars
Thanks! Is this anyhow related to the [https://www.redox-
os.org/](https://www.redox-os.org/) project?

~~~
monocasa
Nope, independent.

------
vectorEQ
here was me hoping in such a modern langauge, perhaps someone would finally
have a good APIC example. alas :D back to the 80s it is. :D it's ok i'll go
back to my acpi document and try not to cry :D !

(cool series! keep it up!!)

~~~
orbifold
You can check out the xv6 64bit port by Brian Swetland. It contains code for
handling the APIC
[https://github.com/swetland/xv6/blob/master/kernel/lapic.c](https://github.com/swetland/xv6/blob/master/kernel/lapic.c)
/
[https://github.com/swetland/xv6/blob/master/kernel/ioapic.c](https://github.com/swetland/xv6/blob/master/kernel/ioapic.c)
and getting multiprocessing to work in 64bit. Pretty concise and nice code.
He's now one of the contributors to Fuchsia.

------
tayo42
Only slightly related, but interrupts are a pretty old concept as far as i
know. I'm curious if there is anything that would replace them?

~~~
anonymfus
Propeller microcontroller uses dedicated cores instead of interrupts.

~~~
AWildC182
Is anyone actually using those in production?

~~~
ddingus
Yes, there are commercial products.

They also get used for industrial automation and data collection.

~~~
AWildC182
....What are the products?

~~~
ddingus
[https://forums.parallax.com/discussion/154310/parallax-
needs...](https://forums.parallax.com/discussion/154310/parallax-needs-
samples-of-your-propeller-commercial-products)

There is some discussion there.

It is a really great device. The two most common exceptions are price and
language support.

In many designs, the chip can replace several.

Early on, yes. Was SPIN and PASM (assembly language, but no where as hard as
one would imagine) Today, C, and other languages are well supported.

It is a true multi-processor. The developer can choose freely between
concurrency and parallelism as needed. Combining code objects is crazy easy
too.

Concurrent can be something like a video display on one core, or COG as they
are known, keyboard, SD card, mouse on another. Once done, those two cores
would appear much like hardware to a program running on another one.

Parallel could be several cores all computing something at the same time.
Doing a mandelbrot set is an example of both.

Main program directs the set computation, one core outputs video, the
remaining ones work a little like shaders do, all computing pixels.

Interrupts could have made a few niche things a tiny bit better. Mostly they
really are not needed.

I had a ton of fun programming and doing some automation with this chip.

It's second gen will tape out, and early revision chips already have. Real
chips, back from the fab for a final round of polish and testing.

On those, every single pin has DAC ADC, a smart pin processor and a variety of
modes and pullups, pulldowns all configurable in softwares. It is a little
like having a mini scope with good triggers on each pin.

Interrupts are present, but no global ones, nor with any ability to interfere
with other cores.

This will keep the lego like feature of grabbing drivers and other code, and
having it act like built in hardware, while at the same time making for event
driven code that is easily shared and or combined with other code.

Interrupts are called events and there are 16 of them, three priority levels,
and that is per core, 8 cores total.

People can build crazy complex things able to input signals or data, process
with high speed accurate CORDIC, and stream data or signals out.

Freaking playground. I have been running an FPGA dev system for a while now.
That is 80 Mhz.

Real chips will clock at 250 Mhz and up through about 350.

------
TomMarius
Awesome series!

