Easiest executable format to start with

[Candamir]

I'm now starting to write multitasking support in my kernel, and I believe it's always nice to test this in some way (even if it's just some characters printing out on the screen...). But instead of supporting a full-fledged format like ELF right from the start, (which I plan to implement later as my default format) I would like to deal with something easy that allows me to focus on the scheduler and such things instead of messing around with all the data structures in a file format...

Is there a way around it?

Candamir

[Ryu]

IMO, the same binary format as the kernel image would be the quickest way to set up tests.

[omin0us]

Just use functions inside the kernel to test your scheduling.

[viral]

well.. you can start with simple functions that can be executed as threads...

Code: Select all

void thread_a()
{
        for(;;)
        {
              printf("a");
        }
}
void thread_b()
{
        for(;;)
        {
              printf("b");
        }
}

once you start executing this functions, try to load simple executebles in plain binary format, so tht you not need to worry about all code,data sections...

[Dex4u]

Here is a very simple, relocatable bin file format.

Code: Select all

org 0
use32
jmp  start
;maybe a simple header here
start:
mov eax,[MyVar1 + ebx] ; you need to do this
mov [MyVar2 + ebx],edx; same with this
mov esi,MyString
add esi,ebx ;  you need to do this
call print ; this is ok like this
jmp LetsGo ;this is ok like this
; some more code here, maybe
LetsGo:
         ret
print:
;print code here
ret

;Data
MyString: db 'hello world!',13,0
MyVar1 rd 1
MyVar2 rd 1

This can be loaded any where in memory, you just need to load ebx with the load address at load time and keep ebx untouched.

I call it the "KISS" file format.

PS: Please do not comment on that it does nothing, as the vars have random data in them etc, its just a demo, to show what needs fixing and what does not.

[Bob the Avenger]

personally i didnt find ELF too bad, the easiest is a flat binary, but i would use something like Dex put if you dont want ELF

KISS really does makes things easier when debugging

[Bob the Avenger]

i was refering to KISS as in the saying "Keep It Simple Stupid" as i have found simple thnigs easier to debug than complicated things

[Solar]

Sure. You don't need to worry about "file formats" when you're trying to debug your scheduler. You can just link the two thread binaries together with the kernel binary (so your bootloader does the loading), and hack together a function that sets up the necessary threads. When you're satisfied with your scheduler, you can extend that hacked function to eventually become your binary loader.

[Bob the Avenger]

thats the way i did it originally, and thats also the way i'm going to redo it

[Warrior]

I'd say ELF, it seems to be well documented and I don't think you have to use all of it's relocation info at first.

[Cjmovie]

http://en.wikipedia.org/wiki/Object_file
Scroll down to "formats" and have a good look, if that helps.

[Ryu]

Dex's code is no differnt then a flat binary or plain binary, which has no file format and bad portability when it comes down to differnt languages. A file format considers some standardizations and whatnot. Usually file format headers or using a flat binary to so something like this in MASM I would consider this a file format and not a simple jmp instruction:

.CODE
ORG 0
;=====================================================================
__InitializeDevice@12 PROC C param3:DWORD, param2:DWORD, param1:DWORD
;=====================================================================
.......
__InitializeDevice@12 ENDP

[viral]

@Candamir
Well before this thread gets too hot.. I would like to show my [very very very] primitive format.. acctually this is not a format but a simple way of writing executables..

Code: Select all

[BITS 32]
[ORG 0x5000]  
START:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
   db   '$TAJ$'      ;Magic number
   dd   0x01      ;Format version
   dd   START      ;Starting address    
   dd   arg      ;Starting address of command line arguements
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
              .
              .
              .
      
;DATA SECTION
   arg resb 32
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

It wont help much, but as I guess u r in very prelimnary stage.. u can get something from this
again i recommend you to check "elf", its really wonderfull..

@Solar, @Ryu : "Situation under controll !!", plz dont make this issues too hot... Dex was just trying to give something very simple, so that Candamir can have idea...

@Dex: plz dont post unnessasary things which can lead u in trouble & i'll miss ur presence.. I saw your fancy DOS games snap shots...

We all are here to share some good things & to make a wonderful, peaceful community.. plz co-operate...

[Crazed123]

well.. you can start with simple functions that can be executed as threads...

Code: Select all

void thread_a()
{
        for(;;)
        {
              printf("a");
        }
}
void thread_b()
{
        for(;;)
        {
              printf("b");
        }
}

once you start executing this functions, try to load simple executebles in plain binary format, so tht you not need to worry about all code,data sections...

If you have some kind of create_thread(entry_point,scheduling_attributes,argument,etc) function, viral's method is probably the best test of your scheduler. Any *real* executable format is a load of work, and if you only want to test your scheduler than executing in-kernel functions as threads will work fine.

[Candamir]

Yes, I think I'll probably go for the approach outlined by Solar, viral and Crazed123. Thanks to everybody for your help and comprehension.

Candamir