On Wed, 2004-09-01 at 02:04 -0300, Martim Carbone wrote: > But in ret_from_intr(), the "iret" instruction hasn't yet been > executed and therefore the interrupt handling hasn't finished. Isn't > the switch from interrupt context to process context done only after > "iret" is executed? Yes, iret initiates the return to the interrupted code. I think you are confusing the formal strict definition of "interrupt context" in a processor kind of view with the more general "from an interrupt handler". The point my book makes is that you must not call schedule() from an interrupt handler. Specifically, when you, the reader, code an interrupt handler, do not ever block from it. This is true. The semantics of whether or not the schedule() call in ret_from_intr is within "interrupt context" is really a different question, and not what I was trying to drive home in my book. I may of been loose in the book with the terms interrupt context meaning the specific processor context and interrupt context meaning inside an interrupt handler, but that is deliberate: the point of the book is not to get overtechnical and bogged down in details, like this email thread. ;-) For the sake of answering this thread, consider interrupt context done when the interrupt handler returns. To kernel hackers, "interrupt context" means "in an interrupt handler." The code in ret_from_intr is in some quasi state in between interrupt context and wherever the kernel is returning to. It is safe to call schedule() there explicitly because the kernel is set up to do exactly that. Hope this makes sense. Robert Love -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
