Hi Wolf,
thanks for your suggestions about the kernel -- user space framebuffer
interaction. However, as this is obviously not the most important part
of your project, I would really prefer a simpler, less intrusive
solution at first. If your user space VESA driver is finished ahead of
time, we can spend some additional time on refining this part.
The kernel console needs only a few pieces of information to operate:
the physical address of the framebuffer and the properties of the
framebuffer (resolution, pixel format, scanline size). This data is
currently received by the kernel from the boot loader (or directly from
the firmware on some platforms). The kernel never does any mode setting
(*) and this should be retained.
Thus the only thing the user space driver should do is to inform the
kernel (using a syscall) that the framebuffer address and properties
have changed. The kernel should do some basic validation of the data and
the kernel code obviously needs to be adapted to be ready for a run-time
change of these parameters, but otherwise the kernel code can stay intact.
(*) Of course, the VESA code in kernel/arch/amd64/src/boot is
technically part of the kernel, but logically it really belongs to the
bootstrapping process and it is executed only once. It is also used only
when booting according to the Multiboot 1 specification. When booting
according to the Multiboot 2 specification, this code is not used.
At first, a couple of indisputable statements:
1. We DONT need anything except ASCII in kernel console.
Let's keep the basic Unicode support in the kernel console intact. This
only allows to render UCS code points if the output device can handle
it, as all char* strings in HelenOS are expected to be in UTF-8. Forcing
the kernel console to be ASCII-only will make things actually more
complicated.
Remember that the kernel console is for debugging purposes only. It
should be possible to compile a production system without it (and
without the kernel even knowing anything about framebuffers, etc.). But
once the kernel console is compiled in, it should render the UTF-8
strings with best effort.
1. Q: How are you going to activate kernel console?
A: Kernel will catch keyboard shortcut.
I don't consider this a good idea. The kernel console can still be
activated by a keyboard shortcut as it is implemented now (Alt+M), but
the current way should be retained: The handling of the keyboard
shortcut should be done solely by the user space, physically activating
the kernel console by the SYS_DEBUG_ACTIVATE_CONSOLE syscall.
The keyboard shortcut activation should definitively not rely on any
kernel keyboard device driver that would observe the keyboard events and
pass them to user space. We don't want to have a USB keyboard driver in
the kernel and we plan to limit the legacy keyboard drivers in the
kernel even furher [a], to make them really minimal and only as a
fail-safe debugging measure.
As the kernel console also activates itself by some major system-wide
events (e.g. a kernel panic), a reasonable compromise would be to
activate it also in case of a NMI or similar hardware event (some
machines have a dedicated physical NMI button). This can be done in a
relatively non-intrusive way. But we should really avoid having complex
keyboard drivers and special keyboard shortcut logic in the kernel.
[a] http://trac.helenos.org/ticket/65
2. Q: In which mode will kernel console work?
A: Since statement 1, it'll be enough to use VGA textmode: 80x25,
80x50 or even 90x30/60.
The kernel should really not attempt to do any mode setting, not even
using the VGA registers. The kernel console should be able to live with
the framebuffer address and properties supplied by the boot loader,
firmware or the user space (if the user space changes the mode).
3. Q: And how are you going to switch to that mode? We won't allow you
to move any complex pieces of code, such as realmode emulator or v86
monitor, into kernel!!!!!
A: I won't use BIOS interrupt to setup mode. I will program VGA
controller directly using existing dumped register values. See [0],
[1], [2].
See my previous reply. I would not object to this idea if HelenOS would
run only on a PC. But this is not the case and your suggestion is
obviously not very portable.
4. Q: How GUI stack will understand that we return from kconsole?
Actually, this is already implemented. The kernel sends the
EVENT_KCONSOLE notification to whoever is listening to it in the user
space (see cmd_continue() kernel/generic/src/console/cmd.c). Both the
compositor server and the console server react by redrawing the contents
of the viewport.
The other half of this handshake could be improved: The compositor still
redraws dirty pixels in the framebuffer even if the kernel console is
activated. But again, the kernel console is only for debugging purposes,
thus it is not a major issue.
A: It will depend on our severity. If we are going to keep mikrokernel
minimal in the sence of codebase and functionaly, kernel will just
release keyboard.
Again, this is already implemented. The "release of the keyboard" is
done via changing the order of delivering the interrupts to the kernel
vs. user space drivers (see irq_dispatch_and_lock() in
kernel/generic/src/ddi/irq.c). With polling-only kernel drivers [a] this
will be even easier.
5. Q: What if system will build without GUI, only with console mode?
A: Now the situation is a bit more complicated. My current view:
kernel keep track of processes mapping VGA textmode memory. On
switching to kconsole, kernel saves vmem content to backbuffer and
remaps processes' pages from vmem to that buffer. On leaving kconsole,
kernel restores content of vmem from buffer and restores mapping.
This is also mostly implemented already. Try compiling HelenOS without
the VESA support (disable the "Framebuffer support" in the configuration
menu, keep only the "EGA support" enabled). This essentially disables
the GUI stack. The keyboard shortcut to switch to the kernel console is
F12 in this case.
M.D.
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
