flat assembler
Message board for the users of flat assembler.

Index > OS Construction > Kernel Debug IO

Author
Thread Post new topic Reply to topic
Tyler



Joined: 19 Nov 2009
Posts: 1216
Location: NC, USA
Tyler
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
Post 20 Jul 2010, 12:55
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4240
Location: 2018
edfed
interrupt seems to be a good choice since it is accessible from anywhere ones it is loaded and linked to IVT or IDT.
Post 20 Jul 2010, 13:01
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17624
Location: In your JS exploiting you and your system
revolution
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.
Post 20 Jul 2010, 13:13
View user's profile Send private message Visit poster's website Reply with quote
Tyler



Joined: 19 Nov 2009
Posts: 1216
Location: NC, USA
Tyler
revolution wrote:
But if instead you have a less lofty requirement
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).
Post 20 Jul 2010, 14:10
View user's profile Send private message Reply with quote
chaoscode



Joined: 21 Nov 2006
Posts: 64
chaoscode
maybe you implement a driver class DEBUG, DEBUG INTERFACE or DEBUGPRINT that prints the text to Serial or screen...
(or ethernet?)
Post 20 Jul 2010, 16:44
View user's profile Send private message ICQ Number Reply with quote
Tyler



Joined: 19 Nov 2009
Posts: 1216
Location: NC, USA
Tyler
> 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. Smile
Post 20 Jul 2010, 17:17
View user's profile Send private message Reply with quote
chaoscode



Joined: 21 Nov 2006
Posts: 64
chaoscode
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...
Post 20 Jul 2010, 18:59
View user's profile Send private message ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
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.
Post 20 Jul 2010, 23:01
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4240
Location: 2018
edfed
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.
Post 20 Jul 2010, 23:06
View user's profile Send private message Visit poster's website Reply with quote
Tyler



Joined: 19 Nov 2009
Posts: 1216
Location: NC, USA
Tyler
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.
Post 21 Jul 2010, 03:07
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.