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.
> In order to be run on bare metal it's needing another bootloader which the documentation only barely mentions.
Maybe it's an in-group vs out-group thing: those in the group (i.e. have attempted this in the past) don't care about what the first stage bootloader is; you'll just use some existing bootloader (I used grub).
If you're in the out-group, you feel cheated that you still need a bootloader.
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?
Zig is supposed to be an improvement upon C, so doing C things with it seems reasonable.
Kind of neat that there's no need for a separate assembly file although there is inline assembly. Might get better (or worse) syntax support for separate assembly files? But it doesn't make a big difference until there's more features that need it (interrupts, threads/processes and maintaining their stacks, syscalls, starting other processors, etc)
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 guess one of good reasons is easy cross-compilation.
But also, I can see some amount of weird hooray optimism in this project, like: totally confusing claim that the thing is bare metal when it's still being run under an emulator; also, calling it a kernel is a huge overstatement
Zig is essentially a substantially improved and enhanced C, both in character and intent. There is a lot to recommend it for applications where you might otherwise use C.
because Zig is simply a better C, often faster (normally at least as fast), but with way more safety guarantees or at least things preventing the vast majority of traditional C footguns from happening
Well, in the real world we need at least polymorphism and operator overloading, but that is against the core Zig philosophy, so serious GameDev ignores it (which ironically one would think is the biggest core market for low level systems programming). Hence why new GameDev development still chooses C++, and Andrew’s project fails to gain a significant boost in users.
WD-42|12 days ago
feb|11 days ago
6r17|12 days ago
pmarreck|12 days ago
karlosvomacka|11 days ago
kunley|12 days ago
In 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?
toast0|12 days ago
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.
lelanthran|12 days ago
Maybe it's an in-group vs out-group thing: those in the group (i.e. have attempted this in the past) don't care about what the first stage bootloader is; you'll just use some existing bootloader (I used grub).
If you're in the out-group, you feel cheated that you still need a bootloader.
ajxs|11 days ago
eddd-ddde|12 days ago
cies|12 days ago
Even saying it "runs" on QEMU is a far stretch: it "halts", that's all it does. :)
(it does run on hardware as per other commenters in this HN convo)
csense|12 days ago
toast0|12 days ago
As it's multiboot, it should likely run on v86 too. It's always fun to have an in browser demo of a little OS like this.
anta40|12 days ago
https://wiki.osdev.org/Zig_Bare_Bones
Yes, just tried it.
flopsamjetsam|12 days ago
> It boots on an x86 (i386) machine via the Multiboot 1 protocol
Yes, it does need a compliant bootloader on virtual or physical hardware.
lopespm|11 days ago
drnick1|12 days ago
toast0|12 days ago
Zig is supposed to be an improvement upon C, so doing C things with it seems reasonable.
Kind of neat that there's no need for a separate assembly file although there is inline assembly. Might get better (or worse) syntax support for separate assembly files? But it doesn't make a big difference until there's more features that need it (interrupts, threads/processes and maintaining their stacks, syscalls, starting other processors, etc)
AndyKelley|12 days ago
kunley|12 days ago
But also, I can see some amount of weird hooray optimism in this project, like: totally confusing claim that the thing is bare metal when it's still being run under an emulator; also, calling it a kernel is a huge overstatement
kennykartman|11 days ago
jandrewrogers|12 days ago
mitchellh|12 days ago
flohofwoe|12 days ago
unknown|12 days ago
[deleted]
pmarreck|12 days ago
6r17|12 days ago
moonlion_eth|12 days ago
boricj|12 days ago
It handles interrupts/traps and targets the aarch64 QEMU virt platform. It also features a HAL.
aryalaadi|12 days ago
benatkin|12 days ago
Also baremetal where the metal is virtual. LLVM uses this term for when an OS isn't available https://github.com/llvm/llvm-project/tree/main/libc/src/stdl...
ajxs|12 days ago
anta40|12 days ago
xx__yy|12 days ago
gethly|12 days ago
messe|12 days ago
qaqqqqaq|11 days ago
[deleted]
xx__yy|12 days ago
smallstepforman|12 days ago
throwaway27448|12 days ago
xx__yy|12 days ago