From b68881abc4c50bbc8ee9e81b4e18b0ea011b83b7 Mon Sep 17 00:00:00 2001 From: Alex Auvolat Date: Mon, 2 Mar 2015 17:55:31 +0100 Subject: Setup critical section management for parts that must not be interrupted. --- src/kernel/include/idt.h | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) (limited to 'src/kernel/include/idt.h') diff --git a/src/kernel/include/idt.h b/src/kernel/include/idt.h index 2cccfa5..45cc3e3 100644 --- a/src/kernel/include/idt.h +++ b/src/kernel/include/idt.h @@ -75,14 +75,13 @@ void idt_set_ex_handler(int number, isr_handler_t func); //Set exception handler void idt_set_irq_handler(int number, isr_handler_t func); //Set IRQ handler // Warning about IRQ handlers : -// IRQ handlers must not call yield(), because that may not return ! Therefore they cannot -// use mutexes, memory allocation and most usefull things. Basically the only thing they -// can do is wake up another thread, so it is a good idea to have a thread that waits for -// the IRQ and does something when it happens, and the IRQ handler only wakes up that thread -// when the IRQ happens. -// Remark on resume_thread : if the second argument is set to true, yield() is called in the -// function, so it may never return in some circumstances -// IRQ handlers are never preemptible +// IRQ handlers may run on the kernel0 stack, which is reset each time the scheduler +// is entered. Therefore IRQ handler routines may not call yield(), which makes them +// unable to use mutexes, memory allocation and most usefull things. Basically the only +// thing they can do is wake up another thread, so it is a good idea to have a thread +// that waits for the IRQ and does something when it happens, and the IRQ handler only +// wakes up that thread when the IRQ happens. They may also communicate via atomical +// or lock free data structures. void dbg_dump_registers(registers_t*); -- cgit v1.2.3