Skip to content

Commit 82287ea

Browse files
authored
Merge pull request #248 from roeeshoshani/next
add an update about genesis
2 parents feb23b1 + 0538713 commit 82287ea

File tree

1 file changed

+45
-0
lines changed

1 file changed

+45
-0
lines changed

content/this-month/2025-01/index.md

+45
Original file line numberDiff line numberDiff line change
@@ -78,6 +78,51 @@ In this section, we describe updates to Rust OS projects that are not directly r
7878
...<<your project updates>>...
7979
-->
8080

81+
### [`roeeshoshani/genesis`](https://github.com/roeeshoshani/genesis)
82+
<span class="maintainers">(Section written by [@roeeshoshani](https://github.com/roeeshoshani))</span>
83+
84+
`genesis` is a bare metal firmware implementation for mips. it implements everything from the bottom up, from
85+
initializing the cpu caches, to configuring pci devices and the interrupt controller.
86+
87+
this month, the core async executor was implemented.
88+
89+
this means that we can implement blocking operations (for example reading a byte from the UART) as rust futures, and we then
90+
`.await` them.
91+
92+
this makes our lives much easier when writing code that needs to block until some I/O events happen. instead of using callbacks,
93+
and having to pass our state all over the place, we can just `.await` the blocking future, and write our code using async functions,
94+
which is much more ergonomic.
95+
96+
##### example
97+
98+
currently, there is only one blocking operation implemented, the operation of reading a byte from the UART.
99+
100+
this allows code like the following to be written:
101+
```rust
102+
loop {
103+
let byte = uart_read_byte().await;
104+
println!("received uart byte: {}", byte);
105+
}
106+
```
107+
108+
which is a huge improvement over the previous implementation of putting the code inside the UART interrupt handler.
109+
110+
##### how does it work?
111+
112+
the way this works is that the core kernel's main loop looks roughly like the following:
113+
```rust
114+
loop {
115+
poll_tasks();
116+
wait_for_interrupt();
117+
}
118+
```
119+
120+
then, the interrupt handler is responsible for waking up the relevant tasks.
121+
122+
futures that need interrupt handlers to wake them up should somehow register themselves, and the interrupt hanlers will then
123+
wake the registered tasks.
124+
125+
then, in the next iteration, the tasks that were woken up will be polled again, which completes the loop.
81126

82127

83128
## Join Us?

0 commit comments

Comments
 (0)