OSDev.org

Ok so I have a bit of a problem I'm trying to figure out. In my x86 OS, I have multitasking working, with one kernel stack per process and every process in its own virtual address space but I'm having some trouble now that I'm rewriting the keyboard driver to accommodate this. Basically I figure that the active user process (in my os this means the one the user switched to with ALT+TAB), should be the only one allowed to read keystrokes. So I figure I'll allocate a ring buffer inside the active process and the keyboard driver will write to it when a key is pressed, great. However when a key is pressed, that's happening from inside an IRQ, so that means it could be fired while inside the address space of ANY process, so it has no idea where the ring buffer it's supposed to write to is!

So I thought of a couple solutions to this problem but none of them seem good:

- Have an address space just for IRQ's and make sure the ring buffer is mapped into this address space and the address space of the active process, this unfortunately means a TLB flush will occur for every IRQ.

- Make sure the ring buffer is mapped into the kernel space of every process, this seems like a hell of alot of overhead for allocating a ring buffer, meaning I have to find all the running processes and allocate inside them

- Temporarily change address spaces while writing to the ring buffer, but once again this is gonna cause a TLB flush

So this seems more fundamental then just rewriting a keyboard driver, but how do you guys make sure you can always access certain dynamically allocated resources from any process?

It sounds like your keyboard driver is integrated into the kernel rather than a separate process.

Assuming that's the case, why do you need more than one ring buffer? The kernel can manage which processes receive keystrokes either by sending the keystroke message only to the foreground application (if you're using some form of message passing) or by tailoring the response to a "get keystroke" system call depending on which application is making the call.

Yes my keyboard driver is part of the kernel, it only ever does anything during an interrupt so this seemed to be the most efficient way to do it.

Ok so, lemme get this straight, I should have one ring buffer, inside the kernel and the interrupt will write to it. when a process that IS active tries to read it removes one press from the buffer. If some other process tries to read from the buffer, it should just return nothing. When the user switches processes, I can simply flush the buffer.

does that all make sense?

PgrAm wrote:
- Make sure the ring buffer is mapped into the kernel space of every process, this seems like a hell of alot of overhead for allocating a ring buffer, meaning I have to find all the running processes and allocate inside them

Most operating systems only change the mapping for userspace when switching between address spaces, the mapping for kernelspace in each process remains identical, so the kernel can map the buffer that the interrupt handler deals with once and have access to it whichever process is currently running.

You may still want to have a separate buffer for each process (all mapped into kernel space where the kernel can see them whichever process is running), though. What happens if the user types a few keystrokes, but the process in focus doesn't read them until the user switches another process into focus? If you just have one keyboard buffer for the whole system, a process could receive keystrokes that the user did not intend for it, and the process they were intended for might never receive them.