Hi Jakub, I must second what Martin said.
> But this also means that severely limiting the features of the kernel > console does not make much sense -- you don't want or need a debugging > tool that is not powerful enough, that is not available or useful when > you need it to debug something, etc. For me, kconsole is invaluable debugging tool when finding root causes of compositor crashes or unexpected behavior. Apart from being able to see compositor stacktrace after page fault or deadlock, it is often very convenient to be able to print "live" values (e.g. mouse coordinates, transformation matrices) to kconsole while interacting with compositor by mouse. Typical scenario is to be switched into kconsole, observe the debug printouts and perform mouse actions leading to some problem (e.g. crash). Note that for having visual feedback from compositor in such situation, it is also crucial for kconsole _not_ to have exclusive ownership of the framebuffer. If I understand correctly the proposed refactoring of kconsole functionality, it seems to me that the debugging features which are currently very robust and isolated, would be suddenly dependent on compositor or console server, both of which are quite complex components that are actively developed and hard to debug without anything under it. Therefore, if you really decide to change the way how kconsole works, my concern would be to maintain the robustness of the current solution. Petr _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
