BareMetal OS
github.com
github.com
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.
Could you elaborate on this? Both ARM and RISC-V have standardized their hardware feature and different target versions.
Is it more on the iterative angle given X86-64 now moves very slowly?
ACPI is available, but not widely supported.
Some hardware uses DeviceTree.
Other hardware just expects you to know what devices are connected and how to interact with them.
https://documentation-service.arm.com/static/60250c7395978b5...
"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
He would say, as I would, that you're much better off with a Forth, but that's another matter :)
"An operating system is a collection of things that don't fit inside a language; there shouldn't be one."
Smalltalk is a VM, the VM isn't 'inside of' the language.
You could argue that an OS is just another high level virtual machine.
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:
https://www.humprog.org/~stephen/research/papers/kell19unix-...
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 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?
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.
- It's not only a kernel, but also have user space
- Code is pretty compact and well documented, in general can be understood in a few days
- No need to spend hours to custom build gcc. Just use the one provided by the distro package manager
The x86 version isn't mantained anymore. They switched to RISC-V.
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.
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.
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.
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.
Hard realtime applications come to mind, though I'm not sure if BareMetal OS is suitable for those?
P.S. Props for saying "Ubuntu or Elementary" -- I switched to Elementary earlier this year and love it so I'm glad it's getting more recognition.
> 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.
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?