Starting with kernel threads instead of user processes/Quest

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
Candamir

Starting with kernel threads instead of user processes/Quest

Post by Candamir »

First: I'm currently implementing multitasking in my kernel and I've worked out a theory: If I start to implement just kernel threads and no user processes, it will be a lot easier as I can spare the TSS and don't have to implement any system calls yet as the thread shares the same code with the entire other kernel, the only difference is that it has its own stack. Is this correct?

Second: My interrupt code just pushes everything on the stack and this info is then available in the C code:

Interrupt handler:

Code: Select all

isr7:         ; For example
    cli
    push byte 0
    push byte 7
    jmp isr_common_stub

isr_common_stub:
    pushad
    push ds
    push es
    push fs
    push gs

    mov ax, 0x10
    mov ds, ax
    mov es, ax
    mov fs, ax
    mov gs, ax

    mov eax, esp
    push eax
    mov eax, fault_handler
    call eax
    pop eax

    pop gs
    pop fs
    pop es
    pop ds
    popad
    add esp, 8
    iret
C code:

Code: Select all

...
struct regs
{
    unsigned int gs, fs, es, ds;
    unsigned int edi, esi, ebp, esp, ebx, edx, ecx, eax;
    unsigned int int_no, err_code;
    unsigned int eip, cs, eflags, useresp, ss;    
};
...
void fault_handler(struct regs *r)
{
...
When invoking the scheduler with r as argument, can I just modify the values on the stack like this r->eax = nextprocess->eax;? If I do it like this, will the eax value on the stack also be modified (this would be great)?

Candamir
DruG5t0r3

Re:Starting with kernel threads instead of user processes/Qu

Post by DruG5t0r3 »

yes thats correct....but you need to remember that if you run "kernel threads" you won't have any protection mechanism between them. Is that really what you want?
Candamir

Re:Starting with kernel threads instead of user processes/Qu

Post by Candamir »

DruG5t0r3 wrote: yes thats correct....but you need to remember that if you run "kernel threads" you won't have any protection mechanism between them. Is that really what you want?
To which of my two questions does that 'yes' refer? Upon the rest of the answer, I guess the first question only, but I might be wrong...

And anyway, I'm not using kernel threads for any servers of my microkernel, but I want to test my scheduler with kernel threads as - repeating myself - I can spare the TSS and don't have to implement system calls (for the moment).

Candamir

PS: Another benefit of starting with kernel threads is that I can focus on the actual scheduling and multitasking mechanisms as I don't have to care about separate address spaces (yet)... ;) But obviously, there isn't much sense in virtual addressing and everything if you don't use it for memory protection between user processes (not kernel threads)...

BTW, please don't forget my second question ;D, if anyone knows...
DruG5t0r3

Re:Starting with kernel threads instead of user processes/Qu

Post by DruG5t0r3 »

the "yes" was for the second question...yes.
Candamir

Re:Starting with kernel threads instead of user processes/Qu

Post by Candamir »

So both my suppositions were correct... Thanks.

Candamir
Candamir

Re:Starting with kernel threads instead of user processes/Qu

Post by Candamir »

While reading infinitys tutorial about multitasking, I didn't quite understand this piece of code:

Code: Select all

        *stacksetup--=0x0202;
        *stacksetup--=0x08;
        *stacksetup--=(uint_t)entry; //This is the adress of the process' entry point (z.b. main());
IIUC, these values mean (in that order) the registers eflags, cs and eip. Is this correct? The value of 0x08 in cs makes sense (because of the GDT), but what does 0x0202 in eflags mean? Is it correct when I set ss to 0x10?

Thanks for helping me

Candamir
User avatar
Pype.Clicker
Member
Member
Posts: 5964
Joined: Wed Oct 18, 2006 2:31 am
Location: In a galaxy, far, far away
Contact:

Re:Starting with kernel threads instead of user processes/Qu

Post by Pype.Clicker »

0x202 in eflags just means you have interrupts enabled. bit 1 of eflags is always set ... if you load eflags with 0x200, you'll read back 0x202 anyway :)

<ot>
back in '97 i started collecting all the info i learn about i386 in a small book ... including the meaning of all bits in EFLAGS ... trust me if you want but it's even faster to check than google ...
</ot>

<edit:oops>
for some reason, i've been having trouble with this post (e.g. hitting "post" did not send me back to the board, but actually _did_ post the message).
</edit:oops>
DruG5t0r3

Re:Starting with kernel threads instead of user processes/Qu

Post by DruG5t0r3 »

Oh so thats how Pype gets so many posts ;)
Candamir

Re:Starting with kernel threads instead of user processes/Qu

Post by Candamir »

Pype.Clicker wrote: <ot>
back in '97 i started collecting all the info i learn about i386 in a small book ... including the meaning of all bits in EFLAGS ... trust me if you want but it's even faster to check than google ...
</ot>
I noticed that too... Most web sites on eflags were very cryptic and hard to understand... Anyway, so does 0x08 stand for cs? And can I set ss to 0x10? And where infinity puts the entry point, is that eip? Thanks

Candamir
distantvoices
Member
Member
Posts: 1600
Joined: Wed Oct 18, 2006 11:59 am
Location: Vienna/Austria
Contact:

Re:Starting with kernel threads instead of user processes/Qu

Post by distantvoices »

Yeah, I set eip to the entrypoint of a kernel thread if I want to create one.

In case of a user level process, I usually use something like 0xdeadbeef to get a page fault for doing some mapping stuff and then setting eip to a fixed value (summat like 0x1000). This successfully starts a user level process.

stay safe.
... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image
Post Reply