Guest post by BareMetal OS v0.4.9 has been released. Newest features are network communication via Ethernet as well as Memory allocation/free functions. BareMetal is an open source 64bit operating system for x86-64 computers. It is written in assembly, and applications can be written in assembly or C/C++. It’s aimed at three target segments (high performance computing, embedded applications, and education). The kernel binary is still under 16 KiB as well!
nice to see a new hobby os that has realistic goals and is well maintained.
… this would make an awesome platform to run memcached on
…the memory requirements are pretty severe.
LOL! J/K.
It looks cool. I am tempted to grab the sources and see how they set up the core queues.
Oh look a BSD-lisenced OS with a proprietary bootloader… wonderful.
ooh… missed that important bit.
less impressed.
… your impression is whether the source code is released or not? Are Stallman Jr?
How about:
Oh, look, a BSD-licensed hobbyist OS that won’t load without the developer’s proprietary, bloated boot loader!
Really, why is a boot loader activating SMP? And why would somebody buy it, just to load 16K of a hobbyist OS?
You do not have to pay for the boot loader, the binary is free to download. The proprietary bit means that the source code has not been released. According to the developer, it might be open sourced in the future:
http://groups.google.com/group/baremetal-os/browse_thread/thread/36…
words are cheap… why not release it now if at all possible… Most likely he can’t open the boot loader having proprietary code in it from elsewhere.
I mean Why Not !
it’s good to have hobby OSes !
It’s very ignorant and arrogant to relegate any substantial work to “hobbyist,” unimportant, or inconsequential.
The code and design is nicely structured. It provides everything many “serious” developer needs to write “serious” applications. Which isn’t a lot.
Unfortunately it’s not a multi-tasking operating system. (Yet? Ever?) I also I disagree with the decision to integrate the library-type (string) routines into the OS.
This would make an excellent, simple, stable lightweight dedicated host operating system for a “serious” software project. Allowing a software developer to FULLY exploit the processing power of a computer.
Cries of “proprietary bootloader?” That sounds like a religious cult crusade to me. Just be happy that the developer(s) were generous enough to release the source.
The main value seems to be in salvaging the BSD code to run from any other 64bit loader, which might not be what the developers intended with this release.
Sure. It couldn’t possible be that forcing you to use a specific boot loader with your OS is incredibly lame.
Hi,
There’s “boot code”, “initialisation code” and the kernel itself. I’d assume that to make the kernel smaller most of the initialisation code is built into the boot code instead.
For things like the code to initialise paging and enable long mode, this is actually a much smarter way to do it than putting the initialisation code into the kernel itself (and then freeing it after it’s used, like Linux does). It makes some things a lot simpler (like linking) because you’re not mixing CPU modes and/or virtual addresses in the same binary; and may mean that the kernel itself is isolated from the boot environment – for example, if the OS is ever booted from 64-bit UEFI (where paging is setup and long mode is enabled before any boot code starts) then maybe you can use the exact same kernel binary (with different initialisation code).
I can’t think of any generic boot loader that currently supports 64-bit. GRUB2 and “multi-boot” might (or might not) have undocumented support for it, but if it does it’d be a moving target (not something that anyone can actually rely on, yet).
I’d also point out that most OSs do have their own native boot loader; and generic boot loaders (like GRUB) could mimic the native boot loader for BareMetal OS (in the same way that GRUB mimics the native boot loader for Linux, mimics the native boot loader for FreeBSD, etc).
– Brendan
I second that. GRUB can set up identity-mapped segmentation in order to load PMode code on x86, it’s just strange that the new releases don’t offer the option to set up some kind of identity-mapped paging and turn on long mode on x86_64. That would be the logical continuation of their previous effort. And much better that linking 32-bit and 64-bit code together in a bastard binary as in their current solution (loading ELF64 without activating long mode), and more generally being forced to maintain a 32-bit and a 64-bit codebase and make them work together…
I haven’t looked at the source at all. However running the .IMG file through the strings command has some interesting stuff in it.