Page 1 of 1
Starting with kernel threads instead of user processes/Quest
Posted: Fri Aug 11, 2006 12:00 pm
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
Re:Starting with kernel threads instead of user processes/Qu
Posted: Fri Aug 11, 2006 3:05 pm
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?
Re:Starting with kernel threads instead of user processes/Qu
Posted: Fri Aug 11, 2006 3:15 pm
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...
Re:Starting with kernel threads instead of user processes/Qu
Posted: Fri Aug 11, 2006 3:19 pm
by DruG5t0r3
the "yes" was for the second question...yes.
Re:Starting with kernel threads instead of user processes/Qu
Posted: Fri Aug 11, 2006 6:34 pm
by Candamir
So both my suppositions were correct... Thanks.
Candamir
Re:Starting with kernel threads instead of user processes/Qu
Posted: Fri Aug 11, 2006 10:09 pm
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
Re:Starting with kernel threads instead of user processes/Qu
Posted: Sat Aug 12, 2006 7:10 am
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>
Re:Starting with kernel threads instead of user processes/Qu
Posted: Sat Aug 12, 2006 8:48 am
by DruG5t0r3
Oh so thats how Pype gets so many posts
Re:Starting with kernel threads instead of user processes/Qu
Posted: Sat Aug 12, 2006 9:08 am
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
Re:Starting with kernel threads instead of user processes/Qu
Posted: Sun Aug 13, 2006 6:32 am
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.