exec abstracts memory (should this be virtual memory? how does exec relate to memory exactly?)
files/filesystems abstract disks
HW support helps with isolation between processes
user/kernel mode + privileged instructions
virtual memory
“The instruction that switches to kernel mode is privileged”
Isn’t there a chicken-and-egg problem here? The instruction that allows privileged instructions to be executed is itself privileged, so how can it ever execute?
I’m probably missing something basic here: is it the case that the kernel process is always running in supervisor mode and that ecall simply transfers control to it, and “the instruction that allows privileged instructions” above only needs to be called once during boot to allow to kernel process to run in supervisor mode? 🤔
Virtual memory makes inaccessible memory unrepresentable for a given process
The kernel has its own address space (is this also virtual?)
ecall to enter the kernel
ecall <system call number>
switch to supervisor mode
syscall()
For user applications that don’t invoke syscalls before their time-slice is up, the kernel uses timer interrupts to seize back control
Monolithic kernel
Tight integration between kernel modules
All code running in privileged mode; large attack surface area
Linux is monolithic / impressive performance
Microkernel
Most kernel modules are implemented as user space servers
The kernel is limited to IPC, a minimal VM implementation, and CPU multiplexing code
User applications send syscalls to the kernel via IPC, the kernel forwards this request to one of its user-space servers, and sends back the result
Doesn’t this imply that the user-space servers need hardware access?
This requires a minimum of four context switches instead of two
Hard to integrate modules; for example: the VM and FS subsystems sharing a page cache
Kernel compilation
proc.c -> proc.s (RISC-V assembly)
proc.s -> proc.o (machine code)
link all .o files into an executable at kernel/kernel (loader)
kernel.asm contains the entire kernel disassembled
Frans went over the boot process in gdb at the end and it was pretty much entirely undecipherable. 😑