prasoc wrote:
What should happen when, let's say, the keyboard interrupt is triggered? Should I disable interrupts for other threads that don't use it, then re-enable it when switching? If so, is there any way to improve this (maybe with some general code for a general IRQ #)? feels a bit hacky this way. is this where I would implement an interrupt mask?
the typical way to do this is:
when an interrupt happens, the interrupt handler is called by the CPU
the interrupt handler does the minimum it has to do to process the interrupt for a simple keyboard driver you might:
-read the keyboard controller and place the value into a ring buffer for the keyboard driver to handle
-tell the interrupt controller you are done (send EOI)
what happens next, depends on if your keyboard driver is itself a separate process, or if it runs in the context of any process:
if your keyboard driver runs in every process (easier to do for a beginner):
-re-enable interrupts and call the keyboard driver code
iret (end the interrupt handler)
if your keyboard driver is a separate process (requires a more sophisticated scheduler):
-tell the scheduler that the keyboard driver needs to run
--at this point the scheduler might immediately switch to the keyboard driver task, or it might schedule the keyboard driver task to run later (or on another core)
-iret (end the interrupt handler)
then, in the keyboard driver:
-take the input value from the buffer, and process it according to the current keyboard state
-if that input represents the end of a keystroke sequence, create a keystroke packet with the information and in the format expected by your programs
-send the keystroke packet to whichever task currently has "input focus"
-check the buffer for more input (if there is more input, repeat)
-if the keyboard driver runs directly, then return
-if the keyboard driver is a task, then tell the scheduler you are done and don't need to run anymore
note this is a simple overview, in real OSes, it is a bit more complex