feat: add PS/2 keyboard interrupt driver

[GloriousAlpaca]

This feature adds support for the PS2 legacy keyboard in Qemu x86_64.
Currently it does:

1. A minimized hardware initialization (e.g. flush the output buffer) to use the keyboard, according to the standards for the Intel 8042 chip: Link to OSDev
2. Install an interrupt handler, which is done in the install_handlers function in interrupt.rs, as it is a hardware interrupt but does not belong in the pci interrupt handlers list (legacy device).
3. Add a systemcall to pop the last scancode out of the keyboard input ringbuffer (which currently has a length of 256). The Ringbuffer also uses Atomics, to prevent races and deadlocks.
   The systemcall returns 0 if the keyboard feature is disabled.

I have only tested this feature with C programs on a Mac using Qemu.

[github-actions]

Benchmark Results

Details

Benchmark	Current: 3c3302d	Previous: 2e23902	Performance Ratio
startup_benchmark Build Time	95.52 s	80.34 s	1.19 ❗
startup_benchmark File Size	0.78 MB	0.80 MB	0.98 ❗
Startup Time - 1 core	0.76 s (±0.01 s)	0.75 s (±0.02 s)	1.02
Startup Time - 2 cores	0.78 s (±0.02 s)	0.74 s (±0.02 s)	1.05 ❗
Startup Time - 4 cores	0.78 s (±0.01 s)	0.74 s (±0.02 s)	1.04 ❗
multithreaded_benchmark Build Time	96.18 s	82.11 s	1.17 ❗
multithreaded_benchmark File Size	0.88 MB	0.86 MB	1.03 ❗
Multithreaded Pi Efficiency - 2 Threads	66.65 % (±6.54 %)	85.89 % (±6.61 %)	0.78 ❗
Multithreaded Pi Efficiency - 4 Threads	40.84 % (±3.51 %)	43.43 % (±2.56 %)	0.94
Multithreaded Pi Efficiency - 8 Threads	19.85 % (±1.41 %)	25.76 % (±1.53 %)	0.77 ❗
micro_benchmarks Build Time	215.41 s	80.40 s	2.68 ❗
micro_benchmarks File Size	0.89 MB	0.86 MB	1.03 ❗
Scheduling time - 1 thread	183.48 ticks (±38.74 ticks)	62.65 ticks (±4.06 ticks)	2.93 ❗
Scheduling time - 2 threads	110.41 ticks (±19.77 ticks)	34.08 ticks (±4.10 ticks)	3.24 ❗
Micro - Time for syscall (getpid)	10.64 ticks (±5.18 ticks)	3.45 ticks (±0.58 ticks)	3.08 ❗
Memcpy speed - (built_in) block size 4096	56760.35 MByte/s (±40204.06 MByte/s)	82448.38 MByte/s (±56997.13 MByte/s)	0.69
Memcpy speed - (built_in) block size 1048576	13760.19 MByte/s (±11354.66 MByte/s)	30585.98 MByte/s (±24707.84 MByte/s)	0.45
Memcpy speed - (built_in) block size 16777216	12352.98 MByte/s (±10294.10 MByte/s)	26340.06 MByte/s (±21720.96 MByte/s)	0.47
Memset speed - (built_in) block size 4096	57211.43 MByte/s (±40574.61 MByte/s)	82292.76 MByte/s (±56891.50 MByte/s)	0.70
Memset speed - (built_in) block size 1048576	14179.65 MByte/s (±11628.45 MByte/s)	31323.85 MByte/s (±25145.86 MByte/s)	0.45
Memset speed - (built_in) block size 16777216	12653.61 MByte/s (±10463.63 MByte/s)	27104.68 MByte/s (±22209.94 MByte/s)	0.47
Memcpy speed - (rust) block size 4096	51355.08 MByte/s (±37562.89 MByte/s)	74097.96 MByte/s (±51811.44 MByte/s)	0.69
Memcpy speed - (rust) block size 1048576	13883.52 MByte/s (±11237.16 MByte/s)	30361.60 MByte/s (±24602.37 MByte/s)	0.46
Memcpy speed - (rust) block size 16777216	11857.50 MByte/s (±9808.02 MByte/s)	27625.34 MByte/s (±22806.88 MByte/s)	0.43
Memset speed - (rust) block size 4096	51818.85 MByte/s (±37876.08 MByte/s)	74373.47 MByte/s (±51976.48 MByte/s)	0.70
Memset speed - (rust) block size 1048576	14269.45 MByte/s (±11492.19 MByte/s)	31110.89 MByte/s (±25033.24 MByte/s)	0.46
Memset speed - (rust) block size 16777216	12188.15 MByte/s (±10007.82 MByte/s)	28386.93 MByte/s (±23265.03 MByte/s)	0.43
alloc_benchmarks Build Time	208.48 s	74.76 s	2.79 ❗
alloc_benchmarks File Size	0.86 MB	0.87 MB	0.98 ❗
Allocations - Allocation success	91.38 %	91.31 %	1.00 ❗
Allocations - Deallocation success	100.00 %	100.00 %	1
Allocations - Pre-fail Allocations	61.60 %	61.44 %	1.00 ❗
Allocations - Average Allocation time	27331.77 Ticks (±1668.24 Ticks)	5860.58 Ticks (±98.43 Ticks)	4.66 ❗
Allocations - Average Allocation time (no fail)	27930.74 Ticks (±2128.87 Ticks)	6554.81 Ticks (±92.86 Ticks)	4.26 ❗
Allocations - Average Deallocation time	5895.06 Ticks (±1872.42 Ticks)	1805.01 Ticks (±250.35 Ticks)	3.27 ❗
mutex_benchmark Build Time	213.90 s	79.82 s	2.68 ❗
mutex_benchmark File Size	0.89 MB	0.86 MB	1.03 ❗
Mutex Stress Test Average Time per Iteration - 1 Threads	36.10 ns (±7.61 ns)	12.10 ns (±0.41 ns)	2.98 ❗
Mutex Stress Test Average Time per Iteration - 2 Threads	32.38 ns (±8.90 ns)	40.26 ns (±1.68 ns)	0.80

This comment was automatically generated by workflow using github-action-benchmark.

[mkroening]

Thanks for the PR! :)

I was wondering why implement drivers for legacy devices instead of USB keyboards (xhci, usb-oxide, embassy-usb). I guess it is because of simplicity.

It would be great to discuss the high-level application-facing API, since that is the hardest to change once merged.

[mkroening]

A scancode can never be zero, right? Returning Option<NonZero<u8>> would be preferable in that case.

[mkroening]

I am not too sure about this API. Is the application supposed to busy loop on this and retrieve one event at a time?

What about doing something similar to Linux's event device (evdev) interface (Linux docs)? Reading from /dev/input/event0 would then fill a user buffer with input events and blocks if no events are there unless opened with O_NONBLOCK.

[GloriousAlpaca]

Since we don't use a filesystem like Linux I would propose something like this:
pub extern "C" fn sys_read_keyboard(buffer: *mut u8 ,size: usize, nonblock: bool) -> isize
(Should I also rename the systemcall to sys_read_pc_keyboard?)
This would be pretty flexible, we can throw standard errorcodes or return the buffersize in bytes like this.
We can then use a semaphore to block the thread until there are scancodes in the vecdeque.

[jounathaen]

I wonder if retaining the keys in the queue is how this is handled best. I'm thinking that maybe adding a timestamp to each key event and discarding it after x seconds is a correct approach. But maybe I'm prematurely optimizing this. It would be interesting to know how other systems are handling this.

[jounathaen]

Suggested change

	## Note that this is not a complete keyboard driver and not needed for general keyboard support.
	## Note that this is not a complete keyboard driver and not needed for serial input/output.

[jounathaen]

Please add a doc comment