adsnaider / harmony Goto Github PK

View Code? Open in Web Editor NEW

1.0 2.0 1.0 42.64 MB

Rust 97.29% Makefile 0.09% Assembly 0.50% GDB 0.08% Shell 0.11% Just 1.93%

harmony's Introduction

Harmony

Harmony OS (pronounced "harmonious") is an experimental, hobby OS written entirely in Rust.

Getting Started

Dependencies

I've only tested this on an x86_64 linux computer. You will need the following tools to build and emulate the OS.

Rust
qemu-system-x86_64 for emulating.
OVMF (currently hardcoded to /usr/share/ovmf/OVMF.fd)
mkisofs for building an ISO.
just for running commands

Emulation with QEMU

There are just rules for building and running the images.

just emulate or just profile=release emulate

This should launch qemu and you should be able to see the OS running. The generated serial.log will include the full serial output.

Additionally you can set debugger=yes to run qemu with a remote debugger.

just debugger=yes emulate

Once QEMU is launched, you can open gdb on a terminal. The .gdbinit should set everything up automatically for you so that you can insert breakpoints and c to start debugging the program.

In order for this to work, you need to include the following in your ~/.gdbinit

set auto-load safe-path \

Testing

Running just test will run unit tests across the entire project.

Running just ktest will run kernel integration tests on Qemu. This will produce a test.log that contains the serial output.

Building an ISO image

just iso or just profile=release iso

This will build the ISO image and save it to .build/[profile]/harmony.iso. You can flash this image to a USB drive for instance and boot from it to see the OS running on actual hardware.

Configuration

Configuration options are passed through environment flags. Currently these are the possible configurations:

RUST_LOG [trace | debug| info | warn | error] - controls the log level (Defaults to info).

The only hardware architecture that is currently supported is x86_64.

harmony's People

Contributors

Stargazers

Watchers

Forkers

wvaviator

harmony's Issues

Lazily allocate pages

Instead of allocating pages and frames when spawning a task, provide a virtual range of memory and only allocate what's needed in the page fault handler.

Switch to a more mature bootloader

Main one the comes to mind is limine since it's built for 64 bit long mode.

Provide a mechanism for handling I/O in user and kernel threads

Figure out how to set a sync invocation stack without a stack

Probably a free-list of stacks where each stack will use itself to point to the next a-la-malloc. Should be able to atomically get the next one and remove from the list.

Set up synchronous invocation call gates

Remove kernel-space printing for userspace

Requires #38

Figure out thread local storage

Implement memory retyping syscalls

We are currently booting by setting up a drive. Ideally, if I want to test in real hardware, I will need to be able to boot from a cd drive.
Setting up the ISO image is not too complicated, but the issue is that to set it up, the kernel image and the font bitmap will not be directly in the floppy and that means that we need to decode the filesystem around the floppy. It's possible that UEFI already provides utility for doing this.

Implement the memory mapping/page table operations

Initialize the Operating System

The rough steps to get to a working state:

Booter should load the memory manager and initialize it.
Booter should initialize the scheduler
2.1. At this point, scheduler takes over thread scheduling
Initialize the file system driver and service
Load the init process from disk and initialize the rest of the system

The above basically encompasses some sort of initramfs (in the future we should make that an actual initramfs). Once the init process is loaded and running, we begin the process of loading the rest of the drivers (maybe even reload some of the drivers like the filesystem or disk).

Handle core-local storage properly

Need to figure out an appropriate API. Similarly, need to figure out how the actual Thread structure fits in all of this.

POC for running processes in usermode.

It's time to try running a usermode process. Eventually I want to start with layer 1 drivers, followed by layer 2 servers, followed by init. Since I just want a POC, we can start with a simple process that is embedded into the kernel. This process will be started and hopefully we will be able to get back to the kernel with a syscall or such.

After completion, we can start thinking about the boot process, how drivers and servers will be loaded and so on and so forth.

Use the IOPB instead of IOPL

Some ports are actually critical for the kernel itself (e.g. A20 gate). Set up per-task IOPB instead per-component

Pros:

Granular access to ports
Per-component enable instead of per-thread (IOPL uses rflags)

Allocate huge pages for untyped memory

Requires #33

Validate user pointer in the kernel

Some syscalls use pointers to structs as arguments. These need to be validated (i.e. bytemuck guarantee that the data will be valid regardless, but the pointer may point to kernel memory, or it can lead to a page fault if we don't check this).

Fix _start function which should assume 16-byte stack alignement

I.e. this is not extern "C". A valid function would be

_start:
  call main
  ud2

where main is
extern "C" main() -> !;

Switch Make to Just

Don't implicitly retype to kernel frames on constructors

Avoid crashing on any user inputs

Clean up the unwraps/expects that don't belong (many of them live in proc

Move framed and bitalloc to their own repos and/or crates.io

It's a bit wonky for a couple of reasons to have these 2 crates in the top level.

CI is awkward because we have to manually test it. Originally I was using cargo workspaces but that is an ill-fitted solution now due to how the bootloader works.
It clutters the OS itself.

In the future, new development of isolated crates can start within the kernel directly and later move out into a crate to become a dependency once it is stable enough.

Read the device tree from ACPI tables

Properly manage tlb caches

The need here is if a user component unmaps a page, leaving it with 0 references, it may still exist in tlb flushes, so the page cannot be retyped until we have a guarantee that it's been flushed from each tlb in the system. This can be done with IPIs or be resetting the Cr3, but that policy should exist in userspace. (i.e. effect in user space but track in kernel space). In the meanwhile, don't allow retyping user frames to kernel