@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.
As I mentioned on IRC, I am in favor of this initiative. Kernel drivers are rather simple, and their simplicity limits uspace drivers competing for the same device. One example in current mainline is pc keyboard: Kernel only accepts xt keycodes forcing uspace drivers to switch at/xt translation (i8042) on, resulting in hybrid usapce driver controlling the keyboard (it reads XT keycodes but uses AT commands to control LEDS). This may seem trivial but it gets more complicated with more complex devices. Another example is serial port drivers on ARM machines (both BBXM and ICP). Kernel serial port driver (BBXM) uses only hw 64 byte FIFO. While this is good enough for human IO, a more complex uspace driver might want to use DMA transfers for serial attached devices (or just because it can). It would make driver switching PITA. Graphics cards might be even better example. Imagine an AMD/ATi card controlled by uspace driver using ATOM Bios controls, sharing a device with kernel VESA driver. There are several ways to fix this: a ) Introduce driver switch framework that would help transfer control from uspace driver to kernel driver and vice versa --I don't think that anyone likes this idea. It was mentioned several times that uspace drivers should not be aware of their kernel counterparts. On the other hand it can be used to switch between two uspace drivers. I ahve no idea whther it would be usefull for anything. b ) Make kernel drivers more robust and capable to save and restore device status when switching to kconsole and back -- I don't that's a good idea either. If kernel drivers are to be more complex we may drop uspace version and save ourselves trouble of maintaining two versions. (see c) c ) Implement some drivers in kernel and provide only uspace stubs (like current kernelfb driver) -- I don't think this the ukernel way of doing things... d ) Make kconsole available to users via uspace drivers. This is achieved by making kconsole accessible from uspace (not only via kernel drivers). I agree that there should be some design to this, and using kernel drivers for early boot output (debug feature) and kernel crashes is good enough, as long as these drivers don't touch devices controlled by uspace drivers. I think input drivers might still be useful for debugging ipc communication deadlocks. 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. Jan On Sun, Nov 25, 2012 at 11:32 PM, Petr Koupý <[email protected]> wrote: > 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 >
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
