Sunday, October 17, 2010

Minix Interrupt Handling





8 comments:

  1. This diagram is cool. Exactly the level of detail one needs. Great work and thanks for sharing.

    ReplyDelete
  2. Btw can you give more detail on Context switching?

    ReplyDelete
  3. Thank you. Yes, the mechanics of context switching is the next logical thing to talk about. That's exactly what I plan to explain with another diagram. Bear in mind that I will have to get into assembly code because most of the context switching happens here. Stay tuned.

    ReplyDelete
  4. Your Blog is a revelation for the MINIX (and OS in general) wannabes. This is the most satisfactory blog I found on the subject. What are your opinions on Tanenbaum - Woodhull MINIX book?

    ReplyDelete
  5. Hi Haritha, the book is very good but hard to read. But I am of the opinion that it is impossible to make a book on operating systems easy. That is the nature of the subject. We have to get comfortable with not understanding things the first time we read them. Hope my diagrams make it easier though. Thank you for your comments. Take care.

    ReplyDelete
  6. Bottom line is: if you want to be an OS expert, if you dream of writing your own OS, then you have to master the Tanenbaum book. I don't know of any other book that can replace it

    ReplyDelete
  7. Hi, I need a small clarification. In step 5.1 of the figure, the CPU set up a new stack at the address pointed to by TSS. By setting up a new stack, I understand that the stack pointer is being set to a new value by the hardware. I just want to know how we are preserving the previous stack pointer (the one used by the interrupted process) if the CPU is immediately switching to the new stack. Does there exist another copy of stack pointer or some thing like that? Thanks.

    ReplyDelete
  8. Hi Haritha, sorry about the delay. No, the stack pointer is not being set to a new value. In step 5.1 and 5.2, the only thing that is happening is that the CPU is pushing several registers (of the interrupted process) to the end of the stackframe structure for the interrupted process in the process table. The stack pointer has not yet changed. Remember that it is always necessary to save all the current registers (including the current stack pointer) before switching context. That is the only way we can come back and resume execution of an interrupted process. Your question is - 'how are we preserving the previous stack pointer?' The answer is that the stack pointer is one of the registers pushed during step 5.2.

    Changing the stack pointer and switching to the interrupt handling code happens only in step 8. Hope this is clear. If not, please let me know.

    ReplyDelete