A simple, language-based OS.
- Simple VGA for seeing output
- Some Rust libraries (core, alloc, collections) already in
- Working (but limited) keyboard input
- Beginnings of a network driver (RTL8139) and stack (it can send properly formatted UDP packets!)
- qemu (emulator) or grub-mkrescue (run an iso on a VM or hardware)
- rustc (1.6.0-nightly)
- cargo (1.6.0-nightly)
- Pull this repo
git clone https://github.com/ryanra/RustOS.git
- Make sure to pull the submodules as well:
git submodule update --init
- On qemu:
- Or, make an iso
make isoand run it on a VM or real hardware!
- Main kernel code now in a fork of rust's libstd
- There is a libstd symlink to the bulk of the code (links to rust submodule at
- Almost RustOS rust code is in
src/libstd/sys/rustos/which is a link to
Implement the entire Rust standard library on bare metal. Essentially, you should be able to write your program, link against
std, add a bootloader, and run on bare metal. Of course, we'll need a little more to make the operating system extensible (specifically, an interface for adding drivers and libraries)
The OS will be as simple as possible with as little as possible in it. Specifically, Rust type safety allows us to omit:
- Paging. CPU memory protection is unecessary if you can only execute safe code
- Syscalls. You can only call functions exported in
std(there is the issue of
unsafethough, which will need to be considered at some point)
- (This simplicitly may also end up scoring in terms of performance!)
Micro/Monolithic kernel is really irrelevant because everything is running in kernel mode and safety is enforced by the language, so there's no need for user mode. That said, the goal is to keep this code base small and enforce least-privledge with tight modules that also allow future additions.
Security. That's the big advantage that Rust would bring to an OS (i.e., memory safety) and that current OSes are really lacking.
Handle interrupts, specifically get the keyboard working.done!
- There's the beginnings of a single-core implementation, but it looks like
libgreencan be slightly modified to this end
- Other architectures:
- There's some beginnings of architecture-agnostic code, but it needs to be taken further
- Basic drivers
- This should include a modular and secure (least privledge) interface for adding your own drivers as well
- A filesystem
- Network stack
- That's probably it!
- Threading is buggy and needs more attention and more features.
- The current allocator never actually frees data and is just there to get