On 11/25/2012 11:32 PM, Petr Koupý wrote: > 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.
How about the possibility to run klog from remcons or some form of future sercons (when we have it)? That would allow you to see everything you described above, independent of proper functioning of the compositor. Alternatively, if we decide to keep the kernel serial driver, we could instruct the kernel to continue to use it as one of its output devices. Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
