max wrote:
Octocontrabass wrote:
So if an IRQ arrives after reading 0x64 to see that no more data is available, but before the driver thread puts itself back to sleep, will the driver thread ever wake up to check again?
Could indeed be a timing issue. I have to rethink my solution.
This indeed brings up the question to me - how do you solve the using of syscalls within an interrupt handler routine? Do you simply not allow it? Or do you directly call the kernel function responsible for it?
What syscalls are you using?
ISR should be quick, read whatever state they need, and get the hell out of dodge as quickly as possible.
As the PS2 controller will have little if any buffering, you're probably best off reading the port 60h contents in the ISR, and posting the resulting value to a FIFO. In fact, you must do it this way, as the only way you can determine which PS2 port the data is read from is by whether you're handling IRQ 1 or 12. How can you otherwise determine this outside of the IRQ, without scheduling races between the respective keyboard and mouse threads?
Writing to a FIFO can be quick, can be easily protected from race conditions, and can easily detect buffer overflow if nothing is reading from the other end of the FIFO (if, for example, your keyboard or mouse driver is hung.) You can have a FIFO each for the keyboard and mouse, which the respective threads read from when data is available.