Implementation Of SachOS(Part 06)
This is the sixth in a series of six articles on the topic. The user mode will be the main topic discussed in this article. I’m following the Reference Book “The little book about OS development” by Erik Helin and Adam Renberg.
I described interrupts and inputs in the last post. Here’s the link to it.👇
I’m using Erik Helin and Adam Renberg’s “The small book on OS development” as a guide for the coding and implementation employees.
Operating systems rely on the kernel, which is at the heart of an operating system. It offers the essential services for all other elements of the OS to function properly. In addition to managing processes and memory, file systems, device control, and networking, it is the fundamental layer between the OS and hardware.
It’s important to remember that the kernel isn’t meant to handle all of the application logic alone. That is left up to the users.
It is the environment in which the user’s programs run, as opposed to kernel mode. User programs will not be able to interfere with other programs or the kernel in this environment since it has fewer privileges than the kernel.
This application will be executed in kernel mode.
Rich operating systems like Windows usually contain drivers and file systems for loading software from a CD-ROM drive, a hard disk, or other persistent media. By using GRUB’s modules, we’ll be able to launch the program without having to create all of these drivers and file systems.
GRUB Modules
If the ISO image is loaded into memory by GRUB, arbitrary files can be loaded into memory. These files are commonly known as modules.
“menu.lst” is stored in iso/boot/grub/. To make GRUB load a module, add the following line to its end.
module /modules/programThe “modules” directory must be created under the “iso” directory in order to hold modules.
After creating the modules directory, we’ll need to change the “loader.s” file to tell GRUB how to load our modules.
Execution of the Program
At this level, a program can only do a few actions. As a consequence, under the “modules” directory, we must save a very simple program. So you must save it as program.s in the modules directory.
Using this command, we have to compile the code into a flat binary.
nasm -f bin program.s -o programAfter the compilation of program.s, we now have both “program.s” and “program” files in the “modules” directory.
Identifying the Program in Memory
We must locate our program in memory, which we can perform fully from C. We’ll give the contents of “ebx” to “kmain” as an argument. To do this, we must first write a header file named “multiboot.h.”
Finally, in order to run the basic program, we must invoke the appropriate functions within the “kmain.” So you may do it this way.
We can now use the “make run” command to execute the operating system. If you’re successful, you’ll see EAX=deadbeef in “bochslog.txt” like this
I believe you have a solid understanding of user mode. This link will take you to my Github repository.
Thank you for reading, and I’ll be back with Part 07 of this article series next week.
