---
# System prepended metadata

title: 'Unikraft Loader, December 7, 2022'
tags: [unikraft, ' loader']

---

---
title: "Unikraft Loader, December 7, 2022"
tags: unikraft, loader
datetime: 2022-12-07T10:30:00+02:00
location: Online, Discord (https://bit.ly/UnikraftDiscord), the `#monkey-business` voice channel
teams:
- loader
participants:
- TODO
---

## :dart: Agenda

- Overview: https://hackmd.io/@unikraft/HyNdSyAki#Unikraft-Loader

## :closed_book: Discussions

MR: First goal is to load the kernel and random addresses.

MR: Also with a multi-boot setup, we aren't able to interpret the ELF sections.
We have more sections.
We need to fix the sections to fall into the correct range.

MR: One question is to have the loader as a Unikraft application or a separate one.

SK: There are trade-offs.

RD: I'm fond of having something working then start trimming it down to make it efficient.

SK: Chainloading will introduce benefits, but it will incur boot time.
This should be a configuration option, to be able to use both options (with and without the Unikraft loader).

MR: You have to be careful about conflicts of resource use by both Unikraft instances.

SK: In the chainloading, the new instances takes over.
The question is how much you can reuse from the old instance.

MR: It's a good question how GRUB does it.
It shouldn't be there when Linux is booted.

MR: The assumption for the paging code is you start from a page table and reuse that.

SK: A GRUB-booted OS will reset / reinitialize the page table.

For starters, Dragoș should get a simple Unikraft image at a random memory address.

## :wrench: TODOs and Decisions

DP: Build Unikraft as a PIE binary.
Start from this PR: https://github.com/unikraft/unikraft/pull/239

DP: Use the build / configure system to build the most minimal `helloworld` image.
