How should it be implemented? How should IO in general be implemented(should kernel print to screen)? Personally, I feel that the kernel itself should do no IO, only drivers should. Doing so is crude and inextensible.

What is a way to provide an interface for kernel dbg messages, while still keeping it extensible? I see the possibility to make my "panic" function hook-able, but what should be done before it is hooked?

What about printf(basic printing to screen), how can it be implemented so that drivers can take over latter?

I'm thinking of implementing an int ?, eax=? call that with esi=ascii str to output, that is just guaranteed to be outputted, just no other guarantees than that, and the int could be hooked by latter drivers.

Please help me with a concept. I know it's annoying for me to be so theoretical, but I want to make my kernel the right way. To me right is: extensible

interrupt seems to be a good choice since it is accessible from anywhere ones it is loaded and linked to IVT or IDT.

Well it depends upon what you want to achieve.

If you want to make general purpose, all singing, all dancing, portable OS kernel then kernel/driver separation is vital.

But if instead you have a less lofty requirement, like maybe a dedicated controller, then kernel/driver (and sometimes kernel/driver/app) separation is often non-existent.

Unfortunately for me sometimes, when I'm really devoted to/interested in something, I'm quite a perfectionist. "general purpose" is close, but I'm more interested in "adaptable to any purpose".

What I want to achieve: Scalable extensibility

My boot model is going to be really simple, my kernel will be a "cpu/memory driver" allowing everything else to be hooked. The hard part is extensibly implementing a kernel dbg logging OUTPUT function. It is simple to have a hookable logger, but to do IO that is extensible is a lot harder. extensible in this case = hookable in a way that will a that the output to one outlet can be halted and redirected to another, or redirected so that it goes to both or etc.(any combination).

maybe you implement a driver class DEBUG, DEBUG INTERFACE or DEBUGPRINT that prints the text to Serial or screen...
(or ethernet?)

> maybe you implement a driver class DEBUG, DEBUG INTERFACE or DEBUGPRINT that prints the text to Serial or screen...
Um... Sorry, but no. That would be a good idea in some kernels with different ideals, but to create a special driver class for debug output seems to take away the whole extensibility concept. I'll make a panic() which can be hooked by those interested in kernel dbg only, but will by default be hooked only by kprintf which will make a call to int 81(Is that commonly used for anything?) eax=0, which will be known as the kernel output interrupt. int 81 being hookable by anything interested in all kernel output.

I know you're reading this and thinking how the f*** is that extensible?! My answer: It's extensible by means of separation and unity. It allows dbg only to be separated and accessed separate from the normal output. int 81 being the unity, all kernel output will pass through int 81 to its correct handler. The default handlers will be built into the kernel itself, but those handlers can be hooked.

What do you think. This has taken a lot of planning. If only I code as much as I plan/theorize/think, I'd have a full fledged Linux 0.0.1.

hmm, thats a good point, but then you have to implement driver code in the kernel just for Output. and then you need a switch, on which device you will send it.
when there is just one simple Module, you can exchange it...

Hooking an interrupt for something like this has a very raw DOS-style feel to it - personally I'd prefer system calls to add/remove a kernel-dbmsg-listener, and have the kernel hold a list of listeners, so arbitrary listeners can be uninstalled at any time.

You'll also have to ponder whether you simply want to be able to output kernel debug messages to different interfaces, or if you want a full-blown kernel debugging interface that you can hook different frontends to (local text/gui, serial, firewire, ...) like NT supports.

otherwise, you can try many many ways to provide I/O for example, a transactional I/O system.

ask for a I/O, and one the I/O is done, receive an ACK, set the transaction as done, and clear it.

F0dder, that's what I'm doing, I use the term "hook" loosely. I provide an interface to "hook" an interrupt, keep them in a list of procs, and call them when the interrupt is fired.

> ask for a I/O, and one the I/O is done, receive an ACK, set the transaction as done, and clear it.
Genius. That's a very good idea, I have to incorporate it somehow.

chaoscode: The code to output will be a dumb terminal driver that may makeup 256 bytes in my kernel. The code to implement a driver class(I haven't started a driver API yet) would probably be a lot more, for little more gain. A program that wants to sit and what for a hooked output could "for(;;)pause();" after they've registered their proc. The could work like a driver, but with less work from me. Maybe after I start on my driver API, I'll attempt your idea. It is a good extensible idea, it's just way ahead of my current situation.