How to run process from kernel

[tomsk]

Hello, I would like to know how can I load and start process from my kernel in the most simplest way.

I don't have filesystem in my OS, so in my opinion it should work like this (I don't know if it is correct), so my process have to be loaded on some specific address and then from kernel I move instruction pointer to that specific address where starts binary code of that loaded process.

This is how my OS looks like:

linker.ld

Code: Select all

OUTPUT_FORMAT(elf32-i386)
ENTRY(start)
SECTIONS
 {
   . = 0x100000;
   .text : { *(.text) }
   .data : { *(.data) }
   .bss  : { *(.bss)  }
 }

loader.asm

Code: Select all

bits    32
section         .text
        align   4
        dd      0x1BADB002
        dd      0x00
        dd      - (0x1BADB002+0x00)
        
global start
extern kernel_main
start:
        cli
        call kernel_main
        hlt

kernel.c

Code: Select all

#include "drivers/keyboard.h"

int kernel_main()
{
        clearScreen();
        print("TomOS v0.1 ");
        putchar('\n');
        putchar('\n');
//here it should call my process to write Hello World

        while (1)
        {
            string ch = readStr();
            print(ch);
        }
}

and I have process saved in file hello.bin which print string Hello World written in Assembly without Syscalls (because my kernel doesn’t support it yet).

So I just wonder how can I load that hello.bin into specific address and then run instructions from that address from my kernel (I don’t have a filesystem so I think linker have to load it to some specific address).

I start my OS with these commands:

Code: Select all

ld -m elf_i386 -T linker.ld -o iso/boot/kernel.bin obj/loader.o obj/kernel.o obj/hardware_communication.o obj/string.o obj/display.o obj/keyboard.o

qemu-system-i386 -kernel iso/boot/kernel.bin

Thank you very much

[Combuster]

What you have is a minimal piece of code that boots. Its does not qualify as a "kernel" in the formal definition of the word, and it still depends on undefined behaviour, such as using GRUB's stack. Then you want a process, which is a rather vague term that depends on how you define it - Even factories have processes, and they are not generally defined in terms of software.

So unless you just want to add a print statement before the last curly brace and call that a process, you should rather start thinking about what defines your "process", and from that you can deduce the kind of components you need.

[tomsk]

By process I mean application, as I said I have Hello World application in Assembly language which outputs Hello World to screen through VideoMemory. So I just want to load it to specific address and run it from kernel (move instruction pointer to that specific address).

[Combuster]

Do you know:
- incbin or bin2obj?
- memcpy?
- how to jump to an absolute address?

Then you should have all the tools to just do it.

[tomsk]

Yes I know that incbin is for including binary code, but I don't understand how when I don't have a filesystem and I don't have access to system libraries.

Memcpy is for copying and I don't know how to jump to absolute address.

Isn't possible to just say linker to load that process to some address? For example my kernel starts at address 0x100000 then I could say that my process will starts at address 0x200000 for example and then in kernel I move instruction pointer to 0x200000 somehow.

[Combuster]

Yes I know that incbin is for including binary code, but I don't understand how when I don't have a filesystem and I don't have access to system libraries.

So basically, you don't

The purpose of such tools is to take any file, and convert it to source code so you can include it in a binary. You get a block of data that then works just like any other variable initialised at compile time: its stored directly in your binary, and you don't need any other further effort to load it from disk. There's no filesystem involved, there are no system libraries involved.


The other two things you mentioned are things that can easily be researched.

[tomsk]

Isn't possible to just say linker to load that process to some address? For example my kernel starts at address 0x100000 then I could say that my process will starts at address 0x200000 for example and then in kernel I move instruction pointer to 0x200000 somehow.

So is this correct?

[tomsk]

So I just used this command for linking my process.

Code: Select all

ld -m elf_i386 -T linker.ld -o process.bin loader.o process.o

linker.ld (for process) contains:

Code: Select all

OUTPUT_FORMAT(elf32-i386)
ENTRY(start)
SECTIONS
 {
   . = 0x500000;
   .text : { *(.text) }
   .data : { *(.data) }
   .bss  : { *(.bss)  }
 }

loader.o (for process) contains:

Code: Select all

bits    32
section         .text
        align   4
        dd      0x1BADB002
        dd      0x00
        dd      - (0x1BADB002+0x00)
        
global start
extern main
start:
        cli
        call main
        hlt

then I merged process binary with my kernel binary with this command:

Code: Select all

cat original_kernel.bin process.bin > kernel.bin

and added jump instruction to address 0x500000 (there should be my process located) into kernel.c:

Code: Select all

#include "drivers/keyboard.h"

int kernel_main()
{
        clearScreen();
        print("TomOS v0.1 ");
        putchar('\n');
        putchar('\n');

        __asm__ __volatile__ ("jmp 0x500000");
        
        while (1)
        {
            string ch = readStr();
            print(ch);
        }
}

then I started my kernel and it starts just fine but my process didn't execute.

[iansjack]

Have you written the routines:

clearScreen()
print()
putchar()
readStr()

[tomsk]

Yea, clearScreen(), print(), putchar(), readstr() works, but my program didn't execute my hello world application at address 0x500000, because it should print Hello World na it didn't.

[Combuster]

there should be my process located

It is not.

As an exercise, post whatever documentation made you believe that.

[tomsk]

there should be my process located

It is not.

As an exercise, post whatever documentation made you believe that.

I thought, so what is correct way to do it?

[dseller]

there should be my process located

It is not.

As an exercise, post whatever documentation made you believe that.

I thought, so what is correct way to do it?

The code for your executable resides at the end of your kernel. Because that’s where you placed it.
If you want it to be at the arbitrary address 0x500000 then you need to put it there first.

[tomsk]

It is not.
The code for your executable resides at the end of your kernel. Because that’s where you placed it.
If you want it to be at the arbitrary address 0x500000 then you need to put it there first.

But how? Can you help me?

[Combuster]

The code for your executable resides at the end of your kernel. Because that’s where you placed it.

Not even that.

The code for that executable is appended after a proper ELF file. qemu has a built-in bootloader that knows how to read ELF files, so it will look at the ELF headers and load what those headers state. It will not see the second ELF file, as there is no entry for that - its just garbage at the end.

There is also no way to tell a linker you are going to append blobs later - after all, that requires a file offset outside of the initial file which is illegal.