OSDev.org

After reaching feature parity with pre-rewrite Orion-X4, I decided why the hell not, announcement time!
Features are quite sparse at the moment, and it's really not the most stable system. It can and will throw tantrums every once in a while -- might want to restart the emulator if that happens

-> Long mode (x86-64) only, sorry 32-bit folks
-> No proper shell, but console-like text rendering on BGA-enabled emulators (Bochs, QEMU and VirtualBox)
-> std* TTYs *should* be functional (PS/2 keyboard supported)
-> PATA DMA driver
-> FAT32 (no FAT16, oops) FS driver
-> Signals (probably)
-> Moderately featured libc and libm
-> Fork() in userspace! (Though it copies all pages at the moment, COW is... difficult)
-> And the newest feature, a mostly functional network stack! (TCP is still shaky)


Again, nothing has been tested thoroughly, and what testing that has been done was only conducted in a limited scope. A lot of code hasn't been touched in a while, and regressions are probably everywhere. Also, it's probably not going to work on Bochs, but you're welcome to try.

Feel free to try this: simply clone the repo
https://github.com/requimrar/mx somewhere (checkout the latest commit from develop, it's usually not broken and master is usually behind), chmod +x the "bootstrap" script if it's not already executable and then execute it.

It'll clone patched GCC and Binutils from bitbucket, then build it (so you can make userspace applications!) (who am I kidding, nobody will), then create a disk image to use with your emulator of choice. Again, I've only tested it on VirtualBox, QEMU and Bochs, the latter of which isn't too good. Note that the OS will output information to COM1, but that the serial driver is quite bad, especially so in VBox (fine on other emulators)

You'll need clang/clang++ to build the kernel, unless you edit the makefile to use the GCC that targets orionx. (x86_64-orionx-gcc). [mx] will also stop the boot process if it can't find a compatible video card -- it usually can work with the standard 80x25 console though, so you can just comment out the code that does the check if you don't want to use the BGA.


TODO:
-> Probably some regression tests before hitting 1.0 (next version is 0.10, not 1.0)
-> Stability, as usual
-> I need to fix TCP (seriously, look at this: http://imgur.com/5RXVql1)
-> The kernel heap has very *very* poor performance right now. The userspace heap is using the same base code, I need to rewrite both, or port something like jemalloc (at least to userspace)
-> Everything else, haha.

I like it.
Is there a reason for your rewrites?

Mostly to maintain some semblance of code cleanliness. The previous versions were created with little thought regarding design and adding more features, so new features (like the FS driver and network socket code) were just piled on with weird hacks and workarounds. A rewrite solved it.

Of course, technically speaking this isn't the 5th rewrite, only the third and a half rewrite... I'm crazy, but not that crazy and don't have that much free time.

But what can be your plans if you have much more free time? Thinking in such direction can improve the efficiency of using your free time. But also it can lead to thoughts like "it's just impossible!". So, be careful