Keyboard Driver issues

Here’s a summary of what needs attention, with

kernel/keyboard.c & kernel/keyboard.h

- No bounds check on scancode index.
Risk of out-of-bounds access with malformed or extended scancodes.

- Extended scancodes (0xE0) not handled Multi-byte scancodes (e.g., arrow keys, numpad) are ignored.

- Modifier keys not implemented Shift, Ctrl, Alt, and CapsLock aren’t tracked — no uppercase or key combos.

- Unsafe terminal output from IRQ terminal_putchar() is called directly from the interrupt handler, which may not be IRQ-safe.

- Backspace behavior incomplete '\b' is added to the buffer but doesn’t remove the previous character or update the terminal.

- Concurrency and buffer issues

key_buffer and buffer_index should be volatile.

buffer_index is uint8_t — risks overflow.

Busy-wait in keyboard_get_char() Works for now, but a blocking/sleep mechanism would be cleaner.

EOI handling not generalized Only sends EOI to master PIC (0x20); slave PIC (0xA0) needed for IRQ ≥ 8.

Limited API in keyboard.h Only keyboard_init() and keyboard_get_char() are exposed — no non-blocking read, peek, or keymap configuration

Start with kernel/keyboard.c and kernel/keyboard.h, then trace keyboard_init(), keyboard_get_char(), terminal_putchar(), and the IRQ path. Review each listed concern against the current driver behavior and existing kernel test or boot workflow. Done requires defining and verifying the scope for scancode handling, modifiers, buffering, terminal output, EOI handling, and the keyboard API.

Written by the indexing model from the issue text.