I will only sum up: kernel debug console, which by definition should be accessible on emergency situations including but not limited to framebuffer driver crashes, instead relies heavily on userspace code.
I see your point. But the solution to this issue is to implement universal mechanisms that would automatically activate the kernel console in case there is some kind of emergency (e.g. when the user space framebuffer driver crashes or when the entire user space gets into some other non-recoverable state).
This could be achieved by implementing the other half of the handshake from physmem_map() (in kernel/generic/src/ddi/ddi.c) that takes care of the kernel stopping its output to the framebuffer once the user space driver takes over. I can also imagine other conditions that might trigger the kernel console activation.
On the other hand, what we really want to avoid are complex device drivers and complex hardware-related logic in the kernel (including mode setting). Because as this code gets more complex there are also more ways it can fail due to the interaction between the code driving the hardware from the kernel and the code driving the same hardware from the user space. There is basically no synchronization between the drivers living in these two worlds and it is arguably impossible (or at least extremely hard) to design such synchronization generically (as the kernel is totally unaware of the I/O devices that are discovered thanks to bus drivers implemented only in user space).
Simply speaking: There should be only one place from which any device is driven primarily. Any other driving place should be used only for emergencies and with minimal (preferably no) interaction with the primary driving place. If we were to develop a monolithic system, the primary place would be the kernel. As HelenOS is a microkernel system, the primary place should be the user space.
M.D. _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
