Virtual terminals vs. kprintf()

[giszo]

Hi!

I'm in the middle of implementing virtual terminals for my OS. During the thinking and design I thought that the kernel log (the output of kprintf) could also get its own terminal so kernel log would be printed to that virtual terminal. This means that kprintf instead of writing to the screen directly should write its output to a file handle. This file handle will be read and handled by the terminal driver.

The described "design" has some problems (at least for me), for example writing to a file handle will lock semaphore(s) that could result in a context switch if the semaphore(s) is/are not free. If I call kprintf() from a code block where interrupts are disabled (for instance) the previously described situation will cause weird effects.

What do you think about this?

giszo

[JohnnyTheDon]

Well since the kprintf output is going to a separate virtual terminal, one option (thats not the best, but is easy and effective) is to write a basic driver that only runs on the kernel log's virtual terminal. Don't use threads, semaphores, etc just write a putchar like function that interfaces directly with the terminal and is only used by kprintf.

If you're using Bochs as your emulator, you may want to take a look at the port e9 hack which can be selected at compile time with a switch (I think its --enable-port-e9-hack or something similar). This outputs all characters written to port e9 onto the terminal that is running bochs. It requires no drivers whatsoever, just use outb in your kprintf function to write characters.

[piranha]

Heres what I do (did, I'm doing GUI now).

I had a defined loglevel of, say 2. So only messages higher or equal to 2 would get printed to the current terminal by kprintf. However, all messages would get printed to the kernel log terminal (for me, terminal 2).

Yeah. That worked well for me. I had the loglevel defined at compile time, through a build script configuration program. I guess you could have the kernel load a config file with it in there though...

-JL

[clange]

Here is my current design:

I split the VGA color text mode video memory into 2 parts: 1 for the kernel and 1 for user space. The memory size is 32 kb which splits into 4 hardware windows each big enough to hold 80x50 characters and attributes. I use the VGA hardware to set the address of the video memory to display.

I have a (very simple) console driver embedded in the kernel which "owns" the first 16 kb. The user space console driver "owns" the other 16 kb. Each driver supports 1 hardware backed line based console and 1 hardware backed "TUI console".

The kernel console implements a put character function that will link with printf() from my klibc. My kernel log function matches printf() but has an extra starting parameter to indicate log level. printf() will simply print to the kernel line console. kernel_log() will filter based on the current log level and the indicated log level. It will also write to the serial port. The kernel TUI is just used for an ASCII splash screen with progress indication.

The user space console driver is more complete. It offers writing, setting color, setting console size, etc. printf() from the user space libc links with a put character function that communicates with the console driver. All this input goes to the user space line console. The console driver offers a bitblt function that copies content to the user space "TUI console". I have written a minimal TUI library that handles all the drawing and then simply use bitblt() to display the result.

The user space console driver also offers a function to select which hardware console should be displayed.

This design has evolved slowly to suit my needs. It is pretty flexible while also pretty simple.

Hope this gives some inspiration.

clange