Sebastian Scholz

And in the process of doing so, we did evaluate multiple things, but there was not a lot of choice for this sort of thing.

We could have also just used regular C debuggers, as in just start a different process with the debugger and then interface with that.

That was one of the other options that we looked at.

I mean, that would basically have been the normal C approach, you know, like just user, like a GDB, for example, as a debugger.

But the benefit of PropOS was that, well, of course it was written in Rust and it allowed for a lot more fine-grained control of what we wanted to do with our integration tests.

For example, we have a system to compile test Rust binaries

and then upload them via Propa S onto the actual hardware and then look at the output and look for certain signals and to make sure that the tests that this binary represents passes.

So that was very easy to do in Rust and using Propa S. And how does that system look like?

Yeah.

So we use VS Code.

And so if we want to develop a new feature or work on some code, the typical workflow would be, so you write your code, you push it onto a new branch.

And as soon as you push, our CI starts.

And it reserves a slot on the flat set.

The interesting thing is that we also use the flat set for manual debugging.

So we have kind of a little bit of a system where you can reserve a slot on the flat set.

During that time, the CI can't run and has to wait.

But if the CI is running, you have to wait for a bit until it's finished.

And so we kind of have a little server, which unsurprisingly is also written in Rust.

Yes, that kind of manages the access to the flat set.

And you wrote that yourself?