So far, we’ve seen many ways to read a file from different programming languages, we’ve learned about syscalls, how to make those from assembly, then we’ve learned about memory mapping, virtual address spaces, and generally some of the mechanisms in which userland and the kernel interact.

But in our exploration, we’ve always considered the kernel more or less like a “black box”. It’s time to change that.

Two years ago, I did part of Advent of Code 2020 using the Rust language. It was a lot of fun, so let’s try it again!

The problem statement

Our input looks something like this:

1000 2000 3000 4000 5000 6000 7000 8000 9000 10000

Each group of lines separated by an empty line is a list of food items an elf is carrying: each line corresponds to the number of calories in that food.

Blog posts that praise Rust are many but funding is generally in short supply.

If even a small percentage of the money Rust saves companies was put back into the ecosystem it would help secure the future of the platform tremendously.

Multiple sources of funding

It is unreasonable going forward to expect the same handful of companies to provide all the funding.

In December 2023, a minor miracle happened: async fn in traits shipped.

As of Rust 1.39, we already had free-standing async functions:

pub async fn read_hosts() -> eyre::Result<Vec<u8>> { // etc. }

…and async functions in impl blocks:

impl HostReader { pub async fn read_hosts(&self) -> eyre::Result<Vec<u8>> { // etc. } }

The year is drawing to a close, and I’m going off on a much-needed holiday next week. This seems like a good time to look back at the past twelve months!

I can’t believe that shipped

2018 was the year of foundational work. As far as “work work” is concerned, I spent the first 9 months finishing up my largest project ever, the itch v25 rewrite.

Time for another Advent of Code 2020 problem!

That one sounds like it’s going to be fun. Our input is pretty much assembly, like this:

nop +0 acc +1 jmp +4 acc +3 jmp -3 acc -99 acc +1 jmp -4 acc +6

So, the first thing we’re going to do is write down some types.

There’s more than one way to approach this problem, but let’s go with this:

#[derive(Debug, Clone, Copy)] enum InstructionKind { Nop, Acc, Jmp, } #[derive(Debug, Clone, Copy)] struct Instruction { kind: InstructionKind, operand: isize, } type Program = Vec<Instruction>;

Welcome back to the “Making our own executable packer” series, where digressions are our bread and butter.

Last time, we implemented indirect functions in a no-libc C program. Of course, we got lost on the way and accidentally implemented a couple of useful elk-powered GDB functions - with only the minimal required amount of Python code.

The article got pretty long, and we could use a nice distraction. And I have just the thing! A little while ago, a member of the Rust compiler team stumbled upon this series and gave me some feedback.

I know what you’re thinking: haven’t we strayed from the whole “content pipeline” theme in this series?

Well… fair. But compiling and distributing software is part of software engineering, and unless you’re in specific circles, I see that taught a lot less than the “just write code and stuff happens” part.

In the previous article, I gave brummi a go. However, we’ve seen that it still doesn’t fit our requirements: we need a tool that’s fast, easy to install and configure, produces beautiful and usable docs.

Yesterday I started building my own documentation generator, and in this series I’ll present the challenges I face and how I solved them. This might show a few ooc tricks, perhaps some software design, some good, some bad, but overall I hope it’ll be a good read!

Welcome back!

In the last article, we did foundational work on minipak, our ELF packer.

It is now able to receive command-line arguments, environment variables, and auxiliary vectors. It can parse those command-line arguments into a set of options. It can make an ELF file smaller using the LZ4 compression algorithm, and pack it together with stage1, our launcher.