MentOS
0.5.2
The Mentoring Operating System
|
MentOS (Mentoring Operating System) is an open source educational operating system. The goal of MentOS is to provide a project environment that is realistic enough to show how a real Operating System work, yet simple enough that students can understand and modify it in significant ways.
There are so many operating systems, why did we write MentOS? It is true, there are a lot of education operating system, BUT how many of them follow the guideline de fined by Linux?
MentOS aims to have the same Linux's data structures and algorithms. It has a well-documented source code, and you can compile it on your laptop in a few seconds!
If you are a beginner in Operating-System developing, perhaps MentOS is the right operating system to start with.
Parts of MentOS are inherited or inspired by a similar educational operating system called DreamOs written by Ivan Gualandri.
Follows the list of implemented features:
Processes and Events
Memory
Filesystem
Input/Output
I will try to keep it updated...
MentOS is compatible with the main unix-based operating systems. It has been tested with Ubuntu, WSL1, WSL2, and MacOS.
For compiling the system:
Under MacOS, for compiling, you have additional dependencies:
To execute the operating system, you need to install:
For debugging we suggest using:
Under Ubuntu, you can type the following commands:
Note: Older versions might have qemu-system-i386
instead of qemu-system-x86
.
Under MacOS you also need to install the i386-elf cross-compiler. The simplest installation method is through Homebrew package manager. Install Homebrew if you don't already have it, and then type the following commands:
Compile MentOS with:
Then, generate the EXT2 filesystem with:
you just need to generate the filesystem once. If you change a program
you need to re-generate the entire filesystem with make filesystem
, but this will override any changes you made to the files inside the rootfs.img
. In the future I will find a way to update just the /usr/bin
directory and the programs.
Boot MentOS with qemu:
To login, use one of the usernames listed in files/etc/passwd
.
The kernel provides ways of printing logging messages from inside the kernel code to the bash where you executed the make qemu
.
These logging functions are:
You use them like you would use a printf
:
By default only message that goes from pr_notice
included down to pr_emerg
are displayed.
Each logging function (they are actually macros) is a wrapper that automatically sets the desired log level. Each log level is identified by a number, and declared as follows:
You can change the logging level by including the following lines at the beginning of your source code:
This example sets the __DEBUG_LEVEL__
, so that all the messages from INFO
and below are shown. While __DEBUG_HEADER__
is just a string that is automatically prepended to your message, helping you identifying from which code the message is coming from.
MentOS supports scheduling algorithms for aperiodic:
It also supports periodic algorithms:
If you want to change the scheduling algorithm, to Round-Robin (RR) for instance:
or you can activate one of the others:
Otherwise you can use ccmake
:
Now you should see something like this:
Select SCHEDULER_TYPE, and type Enter to scroll the three available algorithms (SCHEDULER_RR, SCHEDULER_PRIORITY, SCHEDULER_CFS, SCHEDULER_EDF, SCHEDULER_RM, SCHEDULER_AEDF). Afterwards, you need to
If you want to use GDB to debug MentOS, first you need to compile everything:
Then, you need to generate a file called .gdbinit
placed inside the build
directory, which will tell gdb which object file he needs to read in order to allow proper debugging. To generate the file, just execute:
Finally, you run qemu in debugging mode with:
If you did everything correctly, you should see an empty QEMU window. Basically, QEMU is waiting for you to connect remotely with gdb. Anyway, running make qemu-gdb
will make your current shell busy, you cannot call gdb
in it. You need to open a new shell inside the build
folder and do a:
Now you will have:
make qemu-gdb
also waiting for you,.text
section.By default I placed a breakpoint at the begginning of 1) the bootloader, 2) the kmain
function of the kernel.
So, when gdb starts you need to first give a continue:
This will make the kernel run, and stop at the first breakpoint which is inside the bootloader:
giving a second continue
will get you to the start of the operating system:
This will make the kernel run, and stop at the first breakpoint which is inside the bootloader:
Project Manager:
Developers: