Kernel: Legacy code and design burdens

[Hendiadyoin1]

Since the i386-only days our Kernel grew quite organically, with some old code, concepts and designs not holding up to the current times here I will collect old burdens of interface design and the like

• [ ] Message signaled interrupts go through each their own IRQ handler MSIs can be quite numerous on modern devices, and work fundamentally different from the old IRQ style of interrupts, which are quite restricted in their amount (~255 in our code base, and likely on x86) On RISC-V (and probably aarch64), interrupt numbers are tied to their specific interrupt controller. We currently expect that a specific irq number is unique to a interrupt controller. All external interrupts get routed to the supervisor external irq (9).
• [ ] Deferred calls may need to allocate to be scheduled, with no failure path in sight We have a small (3 item) inline cache for deferred calls, but on very busy systems this cache is quite small, and hitting an OOM condition while allocating a new entry will currently panic the Kernel; We should come up with a more OOM hardened mechanism of deferring events out of interrupts
• [ ] Register names are very x86-centric
  • [ ] instruction pointer (ip) -> Program Counter (pc)
  • [ ] Base Pointer (bp) -> Frame Pointer (frame_pointer)
• [ ] The Memory Manager in general will need a refactor
  • [ ] Page Management Structures are very x86 centric in naming and layout More abstract APIs implemented per Architecture might be a good idea
  • [x] #22720
• [ ] There are at least two kinds of RegisterState-esque structs, and we should sort through their responsibilities and their actual needs
• [ ] Something something Process and ThreadBlocker might need looking at

I will try to keep this list up to date, as things are resolved and new things are found

[kleinesfilmroellchen]

Renaming PageDirectory -> PageTable. The RISC-V spec never uses the former, and I suspect AArch64 is similar.

[ADKaster]

PageDirectory refers to a specific level of page table. I'm not sure if it really makes sense to rename it? It needs a specific implementation on x86_64, even if the RISC architectures we're looking at treat each level of page table the same.