BareMetal OS
Comments
ianseyler
masom
> 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?
caspper69
While the ISAs are (mostly) standardized, the broader hardware support is a mishmash.
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.
Y_Y
What about SBSA, it's not universal but at least it's a target.
https://documentation-service.arm.com/static/60250c7395978b5...
pkphilip
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.
saturn8601
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?
deadbabe
What are some examples of computations
bitwize
The spirit of TempleOS is alive and well!
mananaysiempre
TempleOS is a very different beast—if anything, it’s closer to Lisp machines or the Canon Cat.
messe
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.
uticus
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
vdupras
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 :)
lproven
As Dan Ingalls (implementor of Smalltalk) said:
"An operating system is a collection of things that don't fit inside a language; there shouldn't be one."
benj111
Thats kind of just redefining the OS though, and what a programming language is.
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.
lproven
> 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:
https://www.humprog.org/~stephen/research/papers/kell19unix-...
benj111
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
_Donny
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?
anta40
I still stick with xv6: https://github.com/mit-pdos/xv6-public
- 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.
notorandit
I would give Minix3 a try.
anta40
No doubt it's more feature complete than xv6. Probably will try it on weekend.
notorandit
Don't forget to contact AST in case you get some interest.
xd
I used https://wiki.osdev.org/Resources back it the day and it looks like it's still alive and well!
sunday_serif
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.
Koshkin
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).
miohtama
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?
actionfromafar
Extreme real-time control with total control over jitter etc. Not only fast response time but predictable.
megiddo
Control over jitter would be less ideal for very tight deadlines due to branch prediction, cache misses, instruction counting, etc.
actionfromafar
Yes?
ianseyler
Correct. BareMetal (the kernel) doesn't have context switching or userland. Think of the kernel as just a hardware abstraction layer.
AnotherGoodName
I bet it doesn’t do that well.
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.
vdupras
> 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.
AnotherGoodName
Fun fact I literally implemented a memory pool since most of the allocs were on the same sized structs and did worse than the os allocator.
vdupras
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.
Koshkin
Then maybe a unikernel such as Nanos would work better for your use case.
andai
It says that there's less overhead and higher efficiency, has anyone measured this? I'm wondering how big of a difference it makes.
AnotherGoodName
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.
andai
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?
mrbluecoat
Is there any equivalent for ARM architecture?
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.
exabrial
Everything old is new again :) It's like a renaissance DOS!
binkHN
From the README:
> 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.
wbsun
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?
ladyanita22
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?
wmf
OS performance comes from algorithms and data structures not from compiler optimizations.
notorandit
Os performance depends upon the overhead imposed over workloads. Being that a compilation, a computation or a communication task is a different topic.
ladyanita22
Exactly, and that is a thing for every single piece of software ever written. Doesn't make a difference whether it's an OS or not.
nightowl_games
I wonder what kinds of hardware are supported... Like I'd imagine a keyboard is not
ianseyler
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.
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.