[HN Gopher] BareMetal OS
___________________________________________________________________
BareMetal OS
Author : tosh
Score : 105 points
Date : 2024-12-10 08:32 UTC (14 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| messe wrote:
| 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.
| Koshkin wrote:
| 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 wrote:
| 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 wrote:
| Extreme real-time control with total control over jitter etc.
| Not only fast response time but predictable.
| megiddo wrote:
| Control over jitter would be less ideal for very tight
| deadlines due to branch prediction, cache misses,
| instruction counting, etc.
| ianseyler wrote:
| Correct. BareMetal (the kernel) doesn't have context
| switching or userland. Think of the kernel as just a hardware
| abstraction layer.
| AnotherGoodName wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| Then maybe a unikernel such as Nanos would work better for
| your use case.
|
| https://nanos.org/
| nightowl_games wrote:
| I wonder what kinds of hardware are supported... Like I'd imagine
| a keyboard is not
| ianseyler wrote:
| 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.
| mrbluecoat wrote:
| 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.
| _Donny wrote:
| 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?
| xd wrote:
| I used https://wiki.osdev.org/Resources back it the day and it
| looks like it's still alive and well!
| sunday_serif wrote:
| 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.
| anta40 wrote:
| 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 wrote:
| I would give Minix3 a try.
| andai wrote:
| 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 wrote:
| 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.
| ianseyler wrote:
| 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.
| deadbabe wrote:
| What are some examples of computations
| masom wrote:
| > 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 wrote:
| 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 wrote:
| What about SBSA, it's not universal but at least it's a
| target.
|
| https://documentation-
| service.arm.com/static/60250c7395978b5...
| bitwize wrote:
| The spirit of TempleOS is alive and well!
| mananaysiempre wrote:
| TempleOS is a very different beast--if anything, it's closer
| to Lisp machines or the Canon Cat.
| uticus wrote:
| 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 wrote:
| 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 :)
| binkHN wrote:
| 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.
| ladyanita22 wrote:
| 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 wrote:
| OS performance comes from algorithms and data structures not
| from compiler optimizations.
| notorandit wrote:
| Os performance depends upon the overhead imposed over
| workloads. Being that a compilation, a computation or a
| communication task is a different topic.
| wbsun wrote:
| 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?
| exabrial wrote:
| Everything old is new again :) It's like a renaissance DOS!
___________________________________________________________________
(page generated 2024-12-10 23:01 UTC)