Proposal: Make kernel diagnostics a first-class subsystem

[rabindra789]

I've been thinking a bit about how we want to debug Lych as the kernel grows, and I wanted to throw an idea out here and get some honest feedback before turning it into anything concrete.

Right now, when something goes wrong, Lych already gives us some useful information, the exception type, ESR_EL1, ELR_EL1, SPSR_EL1, the previous exception level, and so on.

That's a pretty good starting point.

But when you're staring at a kernel crash, it still leaves a lot of the detective work to us. We look at one register, then another, try to figure out what the CPU was doing, and eventually piece together a story from scattered bits of information.

So I'm wondering:

What if Lych could help tell us why it crashed, rather than only telling us where it crashed?

For example, instead of just printing a fault address, a kernel diagnostic report could eventually include things like:

• what exception occurred and what kind of access triggered it
• the address involved in the fault
• the important register state at that moment
• the relevant memory mapping and permissions
• the exception level and CPU state
• the last few kernel events before the crash
• a rough call path, if we can reconstruct one

One idea I particularly like is having a very small in-memory circular buffer basically a "flight recorder" for the kernel.

It could continuously keep the last N important kernel events. If something goes wrong, we wouldn't just get the final fault; we'd get a little bit of the story that led to it.

Something as simple as:

last events:
[BOOT]
[MEMORY_INIT]
[FRAME_ALLOC 0x4008B000]
[TASK_SWITCH 3 -> 7]
[PAGE_FAULT]

This isn't meant to introduce some completely new debugging technique. Operating systems have used pieces of this idea for a long time.

What interests me is making diagnosability part of Lych's design from the beginning, rather than reaching a point later where debugging becomes painful and we have to bolt a bunch of tooling onto the kernel.

That said, I don't want this discussion to turn into a new roadmap item just because the idea sounds interesting.

The current roadmap stays as it is.

If this is something people find valuable, I'd rather see it grow naturally alongside the parts of the kernel that need it — memory management, the MMU, exceptions, interrupts, the scheduler, and so on instead of creating a separate "diagnostics phase" and overengineering it.

So I'm mainly interested in hearing what other people think.

1. Would this actually be useful for Lych, or is the current exception output enough for where we are right now?
2. If you were debugging a real kernel crash, what single piece of information would you want to see first?
3. What would you consider a useful minimal first version? In other words, what's the smallest thing we could build that would already make debugging noticeably easier?

I'd genuinely like to hear different opinions here, including if you think this is unnecessary or premature.

This is a discussion, not a proposal I'm committed to yet. I mostly want to see whether this idea resonates with the people who are interested in Lych.