> @petr: I think you misunderstood (or maybe I did). The goal is not to
> remove debugging features currently offered by kconcole, but to find a way
> how to make them available without relying on kernel drivers.
>
> [...]
>
> Unless uspace drivers are written to prevent it, it will be possible to
> write a small app that just forwards user input to kconsole and print output.
> AFAICT even without going through console. This would work really nice with
> serial port and qemu (you get kernel console in terminal).
> off-topic : Using qemu option -hda:fat:rw:./somedir also helps with exporting
> debug logs, although the procedure needed to make the disk available in
> HelenOS makes it a bit unwieldy.

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.
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

Reply via email to