OSDev.org

Hi all. It is better for us to make a OS debugging information standard. Find a place in memory that we don't use, put the debugging information to there. Such as your kernel thread information, kernel memory usage, your slab of your memory allocator. Then we can make a dtrace for everybody.
thanks
from Peter

mcheung63 wrote:Find a place in memory that we don't use, put the debugging information to there. Such as your kernel thread information, kernel memory usage, your slab of your memory allocator. Then we can make a dtrace for everybody.

I like your enthusiasm, but... how would you identify such a memory location? We have exokernels here, microkernels and monolithic kernels. We have single-threading kernels. We have kernels that don't use slab allocation.

I am not sure if there could be a "one size fits all" dtrace. I fear you would end up with a behemoth of a tool that offers many platform-specific options...

Not to mention several other issues like installed memory, type of firmware and complex NUMA systems. It's also dangerous in the sense that it's not forward compatible with other software that may appear in the future.

I think finding a memory location is not hard. Look at something like 0xb8000, people have to follow.
If we have a standard, os developer can make their os < 100% compatible with that standard, then he just use <100% of the feature.

You don't get it. Even the information itself is OS-specific. There is no such thing as universal debugging information! Even something as trivial as "thread information" is impossible to be detailed in such a manner since there are so many ways of handling threads: kernel threads, user threads (no information at all?), scheduler activations, protothreads, microthreading, etc.

Also, the video memory thing is still around ever since the PC days (i.e., the one before PC-XT and PC-AT); it's been around since before auto-configuration so software is backward-compatible with it. May I ask what's wrong with our current (conventional) methods?

I think such a system is best left for implementation by an emulator. An emulator could give information like how many context switches occur each second, how long each context switch took, which memory locations/ranges are getting accessed most for those contexts, and so on. Bochs offers some sort of a debugging system too, doesn't it?

Cheers,
-naota