OPERATING SYSTEM PART-06
welcome my dear friends….
Now that the kernel boots, prints to screen and reads from keyboard — what do we do? Usually, a kernel is not supposed to do the application logic itself, but leave that for applications. The kernel creates the proper abstractions (for memory, files, devices) to make application development easier, performs tasks on behalf of applications (system calls) and schedules processes.
User mode, in contrast with kernel mode, is the environment in which the user’s programs execute. This environment is less privileged than the kernel, and will prevent (badly written) user programs from messing with other programs or the kernel. Badly written kernels are free to mess up what they want.
There’s quite a way to go until the OS created in this book can execute programs in user mode, but this chapter will show how to easily execute a small program in kernel mode.
01.Loading an External Program
Where do we get the external program from? Somehow we need to load the code we want to execute into memory. More feature-complete operating systems usually have drivers and file systems that enable them to load the software from a CD-ROM drive, a hard disk or other persistent media.
Instead of creating all these drivers and file systems we will use a feature in GRUB called modules to load the program.
GRUB can load arbitrary files into memory from the ISO image, and these files are usually referred to as modules. To make GRUB load a module, edit the file
iso/boot/grub/menu.lst and add the following line at the end of the file:
Now create the folder
mkdir -p iso/modules
program will be created later in this chapter.
The code that calls
kmain must be updated to pass information to
kmain about where it can find the modules. We also want to tell GRUB that it should align all the modules on page boundaries when loading them (see the chapter “Paging” for details about page alignment).
To instruct GRUB how to load our modules, the “multiboot header” — the first bytes of the kernel — must be updated as follows:
; in file `loader.s`
MAGIC_NUMBER equ 0x1BADB002 ; define the magic number constant
ALIGN_MODULES equ 0x00000001 ; tell GRUB to align modules
; calculate the checksum (all options + checksum should equal 0)
CHECKSUM equ -(MAGIC_NUMBER + ALIGN_MODULES)
section .text: ; start of the text (code) section
align 4 ; the code must be 4 byte aligned
dd MAGIC_NUMBER ; write the magic number
dd ALIGN_MODULES ; write the align modules instruction
dd CHECKSUM ; write the checksum
GRUB will also store a pointer to a
struct in the register
ebx that, among other things, describes at which addresses the modules are loaded. Therefore, you probably want to push
ebx on the stack before calling
kmain to make it an argument for
02.Executing a Program
A Very Simple Program
A program written at this stage can only perform a few actions. Therefore, a very short program that writes a value to a register suffices as a test program. Halting Bochs after a while and then check that register contains the correct number by looking in the Bochs log will verify that the program has run. This is an example of such a short program:
; set eax to some distinguishable number, to read from the log afterwards
mov eax, 0xDEADBEEF
; enter infinite loop, nothing more to do
; $ means "beginning of line", ie. the same instruction
Since our kernel cannot parse advanced executable formats we need to compile the code into a flat binary. NASM can do this with the flag
nasm -f bin program.s -o program
his is all we need. You must now move the file
program to the folder
Finding the Program in Memory
Before jumping to the program we must find where it resides in memory. Assuming that the contents of
ebx is passed as an argument to
kmain, we can do this entirely from C.
The pointer in
ebx points to a multiboot structure . Download the
multiboot.h file from http://www.gnu.org/software/grub/manual/multiboot/html_node/multiboot.h.html, which describes the structure.
The pointer passed to
kmain in the
ebx register can be cast to a
multiboot_info_t pointer. The address of the first module is in the field
mods_addr. The following code shows an example:
int kmain(/* additional arguments */ unsigned int ebx)
multiboot_info_t *mbinfo = (multiboot_info_t *) ebx;
unsigned int address_of_module = mbinfo->mods_addr;
However, before just blindly following the pointer, you should check that the module got loaded correctly by GRUB. This can be done by checking the
flags field of the
multiboot_info_t structure. You should also check the field
mods_count to make sure it is exactly 1. For more details about the multiboot structure, see the multiboot documentation.
Jumping to the Code
The only thing left to do is to jump to the code loaded by GRUB. Since it is easier to parse the multiboot structure in C than assembly code, calling the code from C is more convenient (it can of course be done with
call in assembly code as well). The C code could look like this:
typedef void (*call_module_t)(void);
/* ... */
call_module_t start_program = (call_module_t) address_of_module;
/* we'll never get here, unless the module code returns */
The program we’ve written now runs at the same privilege level as the kernel — we’ve just entered it in a somewhat peculiar way. For that we need to run our OS
after that run ‘cat com1.out’ command
this the end of this article if you need more knowledge about this refer the below references,
The little book about OS development
This text is a practical guide to writing your own x86 operating system. It is designed to give enough help with the…