> 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.
I guess interacting with kconsole through remcons would cover any debugging scenario I encountered during graphics stack development. Generally, as far as it would be possible to somehow interact with kconsole assuming crashed compositor or console server, I am OK with any solution you will come up with. However, I still suspect that proposed solution would not be strong enough in certain situations. For instance, how would one debug components that are somehow involved in startup and proper functioning of remcons or other such alternatives - I mean critical components like name server, location server or devman. Or is it assumed that those components are stable enough that in the unlikely event of some problem occuring, the more complicated debugging is justifiable? Anyway, after reading all the arguments from you and Jan, I see there is a lot of benefits to the proposed changes, so losing some debugging strength is probably alright. Petr _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
