bitpacked structs, good enums, arbitrary sized integers, optionals + non-nullable pointers, fast compiler, zig fmt, unit testing, ability to use standard library and the rest of the third-party ecosystem on freestanding, std.ArrayList, std.AutoArrayHashMap, std.MultiArrayList, std.crypto, more productive type system, comptime, SIMD, slices, labeled switch continue, error handling, custom panic handler, stack traces on freestanding, error return traces, zero bit types, the build system, package management, aligned pointers, untagged union safety, multi-object for loops, inline switch cases, semantically guaranteed inline functions, inline loops
I'm very surprised it's *that* short - handling one in rust i'm surprised by the very low amount of code to get that up. Thanks or sharing that was a first time reading some Zig for me !
Almost every OS needs a bootloader; but not every OS needs to develop one. Certainly there's some exceptions where there's not really separation between the two functions, but it's not common and most hobby OSes have the distinction unless they're single sector OSes.
The booloader and the kernel are separate stages; they're both interesting, but pick the part that interests you and work on that. With the multiboot standard and existing loaders like ipxe and grub, if you want to write a kernel, there's no need to write your own bootloader.
Otoh, if you want to write your own bootloader, you can do that too, there's plenty of existing kernels to boot.
And yeah, this kernel does nothing. But it would be a reasonable start to a kernel that does things, although you would need to write all the things.
Bare metal in qemu is a little fishy, but it's easier to take a screenshot of qemu than to take a screenshot of a full computer. I would expect this to run on a full computer as long as it supports BIOS booting, and then it would be a bare metal boot and halt kernel.
The kernel is Multiboot compliant, so it's already compatible with real bootloaders. Creating a disk image with a real bootloader wouldn't be much extra code, but if your point is just to demonstrate a 'bare-bones' Zig kernel, is it really necessary?
21 comments
[ 2.6 ms ] story [ 49.7 ms ] threadIn order to be run on bare metal it's needing another bootloader which the documentation only barely mentions.
More on the naming: why to call it kernel?
The booloader and the kernel are separate stages; they're both interesting, but pick the part that interests you and work on that. With the multiboot standard and existing loaders like ipxe and grub, if you want to write a kernel, there's no need to write your own bootloader.
Otoh, if you want to write your own bootloader, you can do that too, there's plenty of existing kernels to boot.
And yeah, this kernel does nothing. But it would be a reasonable start to a kernel that does things, although you would need to write all the things.
Bare metal in qemu is a little fishy, but it's easier to take a screenshot of qemu than to take a screenshot of a full computer. I would expect this to run on a full computer as long as it supports BIOS booting, and then it would be a bare metal boot and halt kernel.
It handles interrupts/traps and targets the aarch64 QEMU virt platform. It also features a HAL.