It’s always fun to see this get brought up on Hacker News! I’m the developer behind BareMetal OS.
Keep in mind that this is all geared toward raw compute and throughput. No ring-3, no multitasking (we do support multiple cores though), and no higher-level abstractions like TCP/IP or full-featured file systems.
While it’s all coded in X86-64 assembly, a rewrite to ARM/RISC-V would be interesting once that hardware is standardized.
Cool idea! I wonder if this may be useful for creating things like consoles, digital readouts etc. A very lightweight GUI library over this which writes directly to the video memory will do the job well.
I've been seeing this project since I graduated college in the early 2010s. Has this been confirmed to be used in production at any known organization or company?
Oh wow, that's a name I haven't heard since I used to frequent the OSDev forums. I had no idea it was still in development. I recall using Pure64 (BareMetal OS's bootloader) to load my own hobby kernel for a while, in between using GRUB2, and writing my own bootloader.
So first, nicely done. But second, why have an OS at all if running only one program and supports only one ISA?
"The operating system is another concept that is curious. Operating systems are dauntingly complex and totally unnecessary. It’s a brilliant thing that Bill Gates has done in selling the world on the notion of operating systems. It’s probably the greatest con game the world has ever seen...
An operating system does absolutely nothing for you. As long as you had something—a subroutine called disk driver, a subroutine called some kind of communication support, in the modern world, it doesn’t do anything else."
- Chuck Moore, interview in "Masterminds of Programming", 2009
As @ianseyler writes below, the kernel should be seen more as a hardware abstraction layer. It seems to fill this role well and minimally. I'm not sure we could definitely say that Chuck Moore would call BareMetal OS unnecessary. Maybe it should just not be called an OS.
He would say, as I would, that you're much better off with a Forth, but that's another matter :)
> Thats kind of just redefining the OS though, and what a programming language is.
Well, yes.
I am not deeply knowledgeable about the detailed history of Smalltalk, but my impression is that Alan Kay had the ideas and Ingalls wrote the code and made it work. He may be excused some bias. :-)
> You could argue that an OS is just another high level virtual machine.
Hmmmm. I think it depends on the OS.
OTOH, and I read this, barely understood it and disagreed with what I understood:
Well a VM is meant to provide a machine agnostic environment.
An os does the same, with the quirk that its processor specific.
If youre writing Posix C, you shouldn't need to care what that software is running on, as long as its Posix. same goes for a Java or Smalltalk VM.
I suppose some things get interesting, when you start thinking in terms of languages. If you want to write to a serial port, is that an OS thing, or is that a library? Same for the file system. Is MSDOS an OS, or a library?
if you want to go ultra minimalist an OS is just locks and privileges. but I don't think anyone would class that as an OS.
The only satisfying answer for me, is the OS as a collection of services. Those services could be in the form of a programming language, but as Mr Kay points out, some bits don't fit in the programming language model.
This then raises the question, of how far you can take the model. 'everything as a file' does quite well, despite not applying to everything
I used BareMetal and Pure64 as a source of inspiration and knowledge while writing an OS as a student. It is simple and well written.
I miss the days of reading AMD64 manuals and directly interacting with my hardware through assembly, and I want to get back to it.
What would be a good entry-point to OS development nowadays?
I have the "FYSOS: The System Core" by Benjamin David Lunt. While I love the series, I wonder what other alternatives there are, perhaps supporting ARM?
I particularly like the mit 6.S081 operating systems course [1].
The course has you make useful extensions to a reimplementation of the XV6 kernel in RISC-V.
This course really helped me start to understand how an OS works and what the hardware software interface really is.
[1] https://pdos.csail.mit.edu/6.828/2020/ — linking to the 2020 class because all of the lectures were uploaded to YouTube to accommodate remote work during the thick of Covid.
A low-overhead environment like this must be perfect for HPC applications, i.e., when you want to use a computer in its primary function (to perform calculations, as fast as possible).
This is a really interesting approach. What are the main bottlenecks something like BaremetalOS solves? Context switches? Copying data forth and back userland? Something else?
Here’s an example. I have a program that does a lot of memory allocation and reallocation. The memory management strategies in modern OS’s work wonders on this, better than a custom allocator I can write in a reasonable amount of time. In bare metal os I would lose this all for the advantage of not loading an os that tends to stay out of the way unless needed anyway.
Where I see use for this is more likely in situations where time to boot is critical but actual resource requirements minimal. Things like a simple kiosk system or embedded hardware.
> Here’s an example. I have a program that does a lot of memory allocation and reallocation.
It's likely that if memory allocation overhead is part of your bottleneck, that using malloc() is actually a bad idea. Other management strategies such as arenas or rolling buffer will likely perform better. They're also trivial to implement ad-hoc.
Of course, you might arrive at the conclusion that the complexity overhead of custom allocation strategies[1] might not be worth it, but in this case, it means speed is not really an issue.
[1]: as well as, maybe, the necessary redesign of the application to fit those allocation strategies more elegantly.
That's possible. Maybe that such OS "unfairly" stacks custom options against its malloc implementation.
But I wouldn't be so sure to claim that such a pool, implemented in assembler on an OS that leaves everything to you, wouldn't outperform the os allocator you refer to. After all, there is fundamentally less information to manage.
FWIW it’s super hard to benchmark since it just doesn’t have many features. There’s no syscall for memory management for a start. So if you have an application that uses this you need to create your own memory routines in that app.
At some point your app that successfully runs on this is doing all the things your os would normally do. At which point the os is superfluous anyway and the biggest optimizations are likely the highly tailored app specific routines you wrote rather than the specific os optimizations.
In the end a fair benchmark on this very minimal os would be an app that makes no syscalls since this doesn’t really support much anyway. If you run an application with no syscalls on a modern Linux with context switching tuned (you can fine tune how the context switching runs other threads) the impact of an os vs this is simply the memory overhead alone.
You just can’t compare this fairly. There’s no reasonable ‘how fast does this handle a malloc syscall vs Linux’ when it doesn’t implement a malloc syscall at all.
I think a fair benchmark would be some kind of task that this OS is particularly well suited for, and then implementing it relatively optimally on both platforms.
Hard realtime applications come to mind, though I'm not sure if BareMetal OS is suitable for those?
> BareMetal OS is an exokernel-based operating system crafted entirely in x86-64 assembly and is designed to provide unparalleled levels of flexibility and efficiency.
Good to see such bare metal work in HN, I feel there has been fewer this type of work nowadays.
Back to the OS architecture, AFAIK, exokernel tries to get rid of the OS overhead (context switching, abstractions, etc.) to improve performance back in 1995. But I assume with modern computers/workload, the OS overhead only takes a tiny piece. Is that the case? Are people still optimizing OS heavily for today's workload like AI/ML/servers?
There was a test with the 1BRC and it was shown that Rust was faster than Assembly (and likely C as well), meaning, a compiler will probably do a better job than a human optimizing code. How sure can someone be that this is indeed performant?
Keyboard is supported. NVMe, AHCI, ATA, and VirtIO for storage. A few gigabit network adapters from Intel, Realtek, and also VirtIO. A 10gbit intel network driver is currently being developed. Send works on it currently.
Keep in mind that this is all geared toward raw compute and throughput. No ring-3, no multitasking (we do support multiple cores though), and no higher-level abstractions like TCP/IP or full-featured file systems.
While it’s all coded in X86-64 assembly, a rewrite to ARM/RISC-V would be interesting once that hardware is standardized.
reply