Saving state of system and clock tasks on Minix 3.1.0

32 views
Skip to first unread message

jsr1...@zasod.com

unread,
Aug 3, 2016, 3:48:46 PM8/3/16
to minix3
I am trying to understand how minix saves state of system or clock task on system call.
From my understanding what should happen is:
System (or clock) task should be first one to run. After initialization system task enters loop and calls receive which cause interrupt to happen. Now, since system task is running in privileged mode (ring 0) CS, EFLAGS and EIP are pushed on current stack (not in slots in process table!?) (according to Intel's IA-32 Architectures Software Developer’s Manual vol. 3, chapter 6.12.1) and _s_call (in mpx386.s) is executed. It saves some other registers (also on system tasks stack), switches to kernel stack and calls sys_call which removes system task from queue, marks it blocked, and picks new process to run, and saves pointer to it in next_ptr. Code in mpx386.s moves pointer next_ptr to proc_ptr and sets ESP to proc_ptr then it  pops some registers (from process table) and jumps to next process.
So, let say some user process sends message to system task. After saving state of calling process (this time in proper slots in process table) kernel unblocks system task and picks it as next to run (by setting pinter next_ptr to point to its slot in process table). Now again ESP is set to next_ptr and restart routine tries to restore state of system task (from process table), but since state was not recorded there old state (one loaded at boot time) should be restored!!!!????

I know this is not what happens since OS works fine, but i don't see how state is saved and where is flaw in my reasoning.

David van Moolenbroek

unread,
Aug 3, 2016, 4:45:35 PM8/3/16
to minix3
Hi,


On Wednesday, August 3, 2016 at 9:48:46 PM UTC+2, jsr16089 wrote:
I am trying to understand how minix saves state of system or clock task on system call.
From my understanding what should happen is:
System (or clock) task should be first one to run. After initialization system task enters loop and calls receive which cause interrupt to happen. Now, since system task is running in privileged mode (ring 0)

It's been a while but the kernel tasks (system, clock, idle) used to run in ring 1 back then; does that answer your question?

Regards,
David

jsr1...@zasod.com

unread,
Aug 3, 2016, 5:15:12 PM8/3/16
to minix3
 
It does. Thank you.
Reply all
Reply to author
Forward
0 new messages