Hi
I had to edit it as it was posted from my cellphone, reason My DSL ip is frequently blacklisted.
So any way, let me discuss now!
I am trying to do multitasking and paging together. What is confusing me now is STACK.
Thanks for clearing Kernel Mapping confusion.
If we will have a look at JamesM tutorials he uses movestack() to relocate stack reason :
"it'll be linked instead of copied when PD is changed "
Lets create a new task ( not fork() ), that task's address space no doubt will have all the kernel space mapped rather linked but when we create that task we will definitely add some new pages to directory, allocated frames, load program from disk and set appropriatly esp, ebp and eip.
I will set esp and ebp to the end of the program (i.e. end of last allocated frame/page) as i plan to load flat binaries and have set let 8KB of stack at compile time in my program, then where lies the problem?
If above is possible as it seems to me as i myself will set stack pointers for my new task avoiding conflict with kernel stack,then
Why JamesM needs stack relocation?
What does it mean actually?
I no I am wrong otherwise JamesM wont have used movestack(), so please correct me!
Thanks a lot
Kernel and user stack Confusion?
Re: Kernel and user stack Confusion?
Hi,
The moving of the stack in my tutorials is a (slightly dirty) workaround for fork(). The initial kernel stack is in kernel space. When a fork() takes place, the new page directory doesn't copy all the kernel code/data into new physical memory - it points to the same physical memory as the parent process. All other pages are copied (all pages outside kernel space).
The obvious reason for this is (a) it would waste space if we didn't and (b) you'd end up with multiple copies of global variables, and no way of sharing them between processes (leading to an inconsistent kernel state).
If a fork() took place and the stack were in kernel space, it wouldn't be replicated. You would end up with two processes sharing the same stack in physical memory, which of course is going to cause corruption.
So, in my tutorials I relocate the stack early on to somewhere outside kernel space, so that when you fork(), the stack is duplicated.
Now, this is a workaround to obtain UNIX-like behaviour. From your problem description you seem to want to set the stack yourself for each process instead of forking. In this case, you can completely ignore the move_stack function call and omit it if you please.
However - The initial stack that GRUB leaves you with is of undefined size and location - one of the things the move_stack call accomplishes among others is to set a known, valid stack. So, if you abandon the move_stack call, try and make your own kernel stack somewhere, as soon as possible.
Cheers,
James
The moving of the stack in my tutorials is a (slightly dirty) workaround for fork(). The initial kernel stack is in kernel space. When a fork() takes place, the new page directory doesn't copy all the kernel code/data into new physical memory - it points to the same physical memory as the parent process. All other pages are copied (all pages outside kernel space).
The obvious reason for this is (a) it would waste space if we didn't and (b) you'd end up with multiple copies of global variables, and no way of sharing them between processes (leading to an inconsistent kernel state).
If a fork() took place and the stack were in kernel space, it wouldn't be replicated. You would end up with two processes sharing the same stack in physical memory, which of course is going to cause corruption.
So, in my tutorials I relocate the stack early on to somewhere outside kernel space, so that when you fork(), the stack is duplicated.
Now, this is a workaround to obtain UNIX-like behaviour. From your problem description you seem to want to set the stack yourself for each process instead of forking. In this case, you can completely ignore the move_stack function call and omit it if you please.
However - The initial stack that GRUB leaves you with is of undefined size and location - one of the things the move_stack call accomplishes among others is to set a known, valid stack. So, if you abandon the move_stack call, try and make your own kernel stack somewhere, as soon as possible.
Cheers,
James
Re: Kernel and user stack Confusion?
Hi
I apologize for delayed reply.
Thanks a lot (really thanks) for this post too.
You know James I always looked at move_stack() from the point of newTask() not from fork() plus i already had set stack like Bran Kernel does.
So this was confusing me.
Thanks a lot
I apologize for delayed reply.
Thanks a lot (really thanks) for this post too.
You know James I always looked at move_stack() from the point of newTask() not from fork() plus i already had set stack like Bran Kernel does.
So this was confusing me.
Thanks a lot