The best way of printing output

[shervingav]

Hello,
I am new to OS development and I don't know the best way to print output.
please help me out....

[Combuster]

I suppose starting with the forum rules should already explain quite a lot.

[alexfru]

I don't know the best way to print output.

For starters, give context and define best.

[Bender]

I don't know the best way to print output.

For starters, give context and define best.

Better: Define 'Output'


shervingav: Output in modern terms isn't limited to the Console but means a variety of things, An ouput can be done to a serial, file, network, etc. and of course the terminal. In fact even sounds and beeps are considered to be a form of an output!

As alexfru said it depends. Usually you'll ouput to the screen, but what if the target system has no screen i.e. no monitor attached? Then you'll want to use serial ports or dump data to disk.

Clearly there isn't any 'best' way. Even if you choose screen there are a variety of options, ranging from VGA Text Modes to VBE graphics modes. The ideal solution always varies from programmer to programmer.

[sortie]

Bare_Bones.

[Brendan]

Hi,

I am new to OS development and I don't know the best way to print output.
please help me out....

I typically have a "big string in RAM" as a log. Several functions (appendString, appendDecDword, appendHexDword, etc) just append characters to the big string; and there's a "flushLog" function that displays the log.

Initially during boot, the boot loader just uses firmware to display strings (either "int 0x10" for boot loaders designed for BIOS, or "EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL" for boot loaders designed for UEFI). Then boot loader sets up the log and appends any characters it already displayed onto it (so that the log contains everything, all the way back to the first things the first piece of code displayed). Boot loader starts another stage I call the "Boot Abstraction Layer" (BAL).

The BAL has an API and manages the log. Its "flushLog" function uses callbacks. When BAL is first started, the boot loader provides a callback that the "flushLog" function uses (so "flushLog" calls the boot loader, which uses either "int 0x10" or UEFI). Eventually (after video is setup properly, etc) the BAL loads "text output" modules which install their own callbacks and the boot loader's callback is removed. This allows me to have several modules for text output (one for sending output to a serial port, one for handling graphics mode frame-buffers, etc) where you can have none or more of these modules at the same time.

The "text output" modules initially talk directly to hardware. The BAL starts the kernel, and the kernel takes over management of the log. The "text output" modules become processes, and the callbacks end up being messages sent from kernel to these processes whenever the "flushLog" kernel API function is called. When appropriate driver/s are started the "text output" module/s stop talking to hardware directly and switch to using the device driver (and their permission to talk to hardware is revoked). Finally, when the OS is "ready" (all necessary device drivers, services, etc running) the log is written to a file; and any "text output" module/s are notified. It's up to them what they do after that (most "text output" modules would terminate themselves, but they could just keep running like a normal application if they want).

Of course what a "text output" module does depends on the "text output" module. For something that does serial port output, it might monitor the serial ports' "RTS" line (to detect if/when a dumb terminal is plugged in); and keep its own "pointer to last character in log sent" so that when characters are appended to the log it only sends the new characters. For something like video display, you might keep track of a "pointer to the previous line at the top of the screen", scan the log and advance the "top of screen" pointer if necessary; then put the characters from the last N lines of the log into a text buffer, convert data in the text buffer (using a built in font renderer) into pixels, then blit the pixel data to the video card's frame-buffer.

In the same way, you could have "text output" module that drives a Braille display, or uses the PC speaker or sound card (Morse code beeps? Speech synthesizer?), or sends it over a network (telnet?), or controls a flashing infra-red LED, or sends it to a printer, etc. You could even have a module that doesn't display it at all, but just sits there waiting until the OS is "ready" (and then maybe sends the log as an email to someone).


Cheers,

Brendan