SerenityOS/serenity

Kernel: Legacy code and design burdens

开放

#22,865 创建于 2024年1月19日

 (2 条评论) (0 个反应) (0 位负责人)C++ (3,328 个派生)batch import
help wantedmigrationrefactoringtask list

仓库指标

星标
 (33,171 个星标)
PR 合并指标
 (平均合并 5天 11小时) (30 天内合并 35 个 PR)

描述

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
    • #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

贡献者指南