Well, I am not sure who did not understand whom, but my point was that in > case > of compositor or console server crash, it would be a problem to move > debugging > input/output around if it was supposed to go through either of them. And > that > would be especially painful if you actually want to debug e.g. compositor. > As > you suggested, there could be some workarounds how to make the debugging > info > travel via some alternative paths, but I am still not sure whether it > would be > as robust and cover as many debugging scenarios as the current solution > does. >
This is the part that I don't understand. If anything, providing uspace access to kconsole would expand debugging capabilities. You will be able to use remcons for debuging, or serial console. You can even write to the same framebuffer without going through compositor (unless the fb driver is written to avoid providing the same framebuffer to different tasks). I don't consider any of these options to be workarounds jan > That being said, I completely understand the motivation behind simplifying > driver interactions you described - it is even possible that its importance > outweights the preservation of debugging robustness/convenience, but I > don't > have enough insight to judge it. I think the good question is, what parts > of > userspace may crash (or alternatively what parts must keep running) so you > are > still able to interact with kconsole. Because any such component that must > keep > running would be obviously critical for debugging and at the same time it > would > be complicated to debug it in case it was faulty. Therefore, such > components > should not be too complex. > > I hope I made myself clear this time. > > Petr > > > _______________________________________________ > HelenOS-devel mailing list > [email protected] > http://lists.modry.cz/cgi-bin/listinfo/helenos-devel >
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
