https://github.com/floffah/lazers
my attempt at operating system
https://github.com/floffah/lazers
operating-system rust
Last synced: 2 months ago
JSON representation
my attempt at operating system
- Host: GitHub
- URL: https://github.com/floffah/lazers
- Owner: Floffah
- License: mit
- Created: 2026-03-08T14:26:29.000Z (4 months ago)
- Default Branch: main
- Last Pushed: 2026-03-15T01:20:47.000Z (3 months ago)
- Last Synced: 2026-04-18T13:35:11.496Z (2 months ago)
- Topics: operating-system, rust
- Language: Rust
- Homepage:
- Size: 364 KB
- Stars: 0
- Watchers: 0
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
- Agents: AGENTS.md
Awesome Lists containing this project
README
# Lazers
Lazers is a from-scratch operating system project so I can learn about OS design and implementation by building one myself. This is a learning & portfolio project.
If this were ever to be finished it would stand as a practical, modular, modern OS that can run on real hardware, and is specifically for lazy developers (laz-ers) who want to write code not configure their environment.
Thought I'd make it public in case anyone else finds it interesting or useful, but it's really just a personal learning project and not intended for anyone else's use. The code is MIT licensed, so if you want to copy anything, go for it.
## Principles
- Lazers is primarily written in Rust with a small amount of assembly harnesses.
- Structured as a monorepo, but boot, kernel, and userspace code are separate, but may share libraries when it makes sense.
- The kernel specifically is a modular monolith (or aims to be), but userspace is on its own and can evolve separately.
- Structure is self-explanatory
- Avoiding UNIX/DOS heritage where possible, but not dogmatically. If a convention serves the system well, it can be adopted; if it doesn't, it can be reinvented.
- Low coupling where possible and minimal shortcuts
## Checkpoints
This is the high-level roadmap for Lazers as it exists now. It tracks major capability checkpoints rather than every version bump.
### Complete
- [x] Monorepo workspace with separate boot, kernel, shared library, userland, tooling, and architecture areas
- [x] Real `UEFI -> loader -> kernel` boot path on `x86_64`
- [x] Shared `BootInfo` handoff from loader to kernel
- [x] Kernel-owned framebuffer text output
- [x] Keyboard input reaching the running system
- [x] Terminal-style text runtime with process `stdin`, `stdout`, and `stderr`
- [x] Cooperative kernel scheduler with explicit `Process` and `Thread` models
- [x] First real user-mode boundary with syscall handling
- [x] Kernel-owned paging and per-process address spaces
- [x] Shared `ELF` parsing/loading path for boot and runtime executable loading
- [x] Raw GPT disk image with separate `LAZERS-ESP` and `LAZERS-SYSTEM` partitions
- [x] AHCI/SATA disk access in the kernel
- [x] Runtime root filesystem mounted from the system partition
- [x] Disk-backed user executable loading from `/system/bin/...`
- [x] `liblazer` bootstrap runtime for early userland programs
- [x] User-initiated child process spawn and synchronous wait
- [x] First shell as a normal userland program: `lash`
- [x] First external user commands: `echo`, `ls`, and `pwd`
- [x] Process-owned current working directory with inherited cwd on spawn
- [x] First shell built-ins that must affect the shell process itself: `cd` and `exit`
- [x] Userland `argv` exposed through `liblazer::args()`
- [x] Read-only file access from userland beyond directory listing and first file-content command: `cat`
- [ ] Better shell command parsing beyond split-on-space tokenization
- [x] First in-OS status-based userland self-test command: `selftest`
- [x] Host-visible serial logging for kernel and primary terminal output
- [x] Host-captured selftest workflow through `just selftest`
- [ ] Richer command argument support across userland programs
- [ ] More core commands beyond the bootstrap set
- [x] Top-level process exit policy that shuts the system down when `lash` or `selftest` exits
- [ ] Filesystem write support
- [ ] VFAT long-name support or a deliberate replacement strategy
- [ ] A fuller userland process model beyond synchronous spawn-and-wait
- [ ] Timer-driven preemption
- [ ] SMP / multicore support
- [ ] A more complete userland runtime beyond early `liblazer`
- [ ] A real package of day-to-day user programs beyond the current bootstrap set
- [ ] A real installer/update path for writing Lazers onto target hardware
- [ ] Broader boot/runtime support outside the current `UEFI x86_64` path
- [ ] Long-term filesystem direction beyond the current FAT32-first runtime setup
- [ ] Far future higher-level graphics and windowing stack beyond the text terminal
## Build entry point
Use `just` as the primary task runner for repository workflows.
Important tasks include:
- `just setup-toolchain` - install Rust toolchain components and target specifications
- `just run` - Builds everything, assembles the disk image, and runs it in QEMU with GUI
- `just run-headless` - Same as `just run` but runs QEMU in headless mode and saves a screenshot of the framebuffer output to `build/qemu-headless.png` hopefully after boot (for debugging kernel really)
- `just run-selftest` - Boots the kernel into self-test mode, via the selftest binary.
- `just run-selftest-headless` - Same as `just run-selftest` but captures a headless screenshot
- `just selftest` - Boots the selftest image headlessly, mirrors in-OS serial output to the host console, saves it to `build/selftest-serial.log`, and fails if the final selftest summary reports any failures or is missing
- `just check` - runs a monorepo wide `cargo check`
- `just test` - runs all rust tests and selftest
- `just clean` - cleans build artifacts across the monorepo
Other tasks for debugging and development include:
- `just build-loader` - builds the UEFI loader only
- `just build-kernel` - builds the kernel only
- `just build-user` - builds the user binaries only
- `just image` - assembles the disk image from the boot, kernel, and user artifacts
- `just image-selftest` - assembles a separate image that launches `/system/bin/selftest` as the first user program
## Running
If running on macOS or Linux, make sure you have Rust installed with the correct toolchain (`just setup-toolchain`) plus the host-side packages needed for QEMU, OVMF firmware, and disk image creation.
Then all you need to do is run `just run` and everything will be built and you'll see the QEMU window pop up running lazers. Exiting the top-level `lash` shell powers the system off.
For actual hardware, I've not tested this, but it's probably possible.
Likely all it involves is building it on a supported host, running `just image`, and then flashing the resulting `build/lazers.img` to a disk drive or USB and booting from that on UEFI (x86) hardware.
## Development
Tooling now supports macOS and Linux hosts. Generic entrypoints live under `tools/scripts/`, while host-specific implementations live under `tools/scripts/macos/` and `tools/scripts/linux/`.