Still working through the keyboard handler and updating it for Octopus. I've settled on the basic functions that a character device needs to expose so the keyboard handler now looks like a character device.
I've also made use of the stub functions for process_lock() and process_unlock() to allow the keyboard read() function to block until some keyboard data is available. Currently process_lock() just does a spinlock as I haven't migrated the multi-tasking code yet, but as the keyboard is an interrupt-based device it doesn't hang the kernel forever.
The DOS layer has its list of DOSDevices into which the keyboard is being registered, and the interrupt system has a list of interrupt handlers into which a handler for IRQ 1 is being added.
A logical consequence of the way that the object-orientated device drivers are now working, I've had to enhance the interrupt handler so that a pointer to some kind of context object (the object instance, the state, whatever you want to call it) gets passed in when the interrupt is registered, and then gets passed back to the interrupt handler when the interrupt occurs. In the case of the keyboard handler, this is a "keyboard context" object that contains, amongst other things, the keyboard input buffer itself.
I can see how this interrupt context will be really useful for all the other interrupt handlers, and I'm kind of annoyed that I didn't think of it when writing the original DriveAccess kernel as it would have made life a lot simpler.
No comments:
Post a Comment