Mentoring Operating System
An open-source educational operating system for learning how kernels work by reading, running, debugging, and changing a real codebase.
MentOS makes operating-system internals concrete, inspectable, and modifiable. Rather than hiding difficult mechanisms behind a teaching framework, it exposes students to a real kernel codebase while keeping the system small enough to study.
Its design follows familiar Unix, POSIX, Linux, and x86 concepts where practical. The aim is not only to show what an operating system does, but to let learners trace how and why it does it.
| If you are... | Start with... | Then... |
|---|---|---|
| A student learning operating systems | Getting Started and Architecture | Pick a subsystem, follow it into the source, run MentOS, and experiment |
| A contributor | MentOS and the contribution guidelines | Reproduce an issue, make a focused change, add validation, and open a PR |
| An educator | MentOS Wiki | Use the implementation to connect OS theory with executable examples |
| A systems programmer | MentOS source tree | Explore, debug, review issues, or contribute focused subsystem improvements |
| Resource | Purpose |
|---|---|
| MentOS | Kernel, C library, userspace, tests, build system, and main development repository |
| MentOS Wiki | Student-oriented explanations, architecture notes, build instructions, and subsystem guides |
| Project website | Public overview of the project and its history |
| Contributing | Organization-wide contribution expectations and development workflow |
You do not need to understand an entire kernel before working with MentOS. A useful learning loop is:
- Learn the concept — read the relevant Wiki page and identify the problem the subsystem solves.
- Find the implementation — locate the corresponding kernel, library, or userspace code.
- Run it — build MentOS and boot it in QEMU.
- Observe it — use logs, tests, and GDB to follow the execution path.
- Change one thing — make a small modification and predict its effect.
- Validate the result — rebuild and use the available test infrastructure to check your reasoning.
If a page uses terminology you do not know yet, treat that as part of the exercise: operating-system development combines software engineering with architecture, ABI, compiler, filesystem, concurrency, and hardware concepts.
MentOS contains hands-on implementations of many core operating-system topics:
- boot and early kernel initialization;
- x86 segmentation, interrupts, exceptions, and privilege transitions;
- processes, scheduling, context switching, waiting, and signals;
- virtual memory, paging, page faults, and memory allocators;
- system calls and the userspace/kernel boundary;
- VFS, EXT2, ProcFS, files, inodes, and file descriptors;
- pipes and other inter-process communication mechanisms;
- ELF loading and process image replacement;
- device drivers and low-level hardware interaction;
- a C library and userspace programs built on top of the kernel ABI.
The project is intentionally useful at more than one level: you can study a concept from the Wiki, inspect its data structures, trace its execution path, and then test the behavior in a running system.
Good contributions are usually small enough to explain and validate clearly. Examples include:
- fixes for reproducible kernel or userspace bugs;
- regression tests for previously broken behavior;
- clearer explanations, diagrams, and student-oriented documentation;
- improvements to build, test, and debugging workflows;
- focused subsystem enhancements with a clear motivation.
When possible, a technical change should answer four questions:
- What is wrong or missing?
- Why does it happen?
- Why is this the correct layer to fix it?
- How do we know the change works?
Please read the organization-wide contribution guidelines before opening a pull request. Repository-specific instructions take precedence where they exist.
MentOS is both software and teaching material. Changes should therefore aim for:
- Correctness — behavior should be testable and technically defensible.
- Clarity — implementation choices should remain understandable to learners.
- Focused changes — small, reviewable steps are easier to reason about and teach from.
- Evidence — bugs should be reproduced when possible, and fixes should include validation.
- Pedagogical value — documentation should explain concepts rather than assume expert knowledge.
- Traceability — students should be able to connect a concept to the code that implements it.
Questions, bug reports, documentation improvements, and feature proposals are welcome through the relevant repository's issue tracker.
When reporting a problem, include enough information for another person to investigate it: environment, commands, observed behavior, expected behavior, and logs or reproduction steps where useful.
Read the code. Run the system. Break it deliberately. Understand why. Improve it.
