Messages in this thread | | | Date | Fri, 26 May 2006 09:08:01 +0200 | From | Helge Hafting <> | Subject | Re: OpenGL-based framebuffer concepts |
| |
Alexander E. Patrakov wrote: > Helge Hafting wrote: >> Now, a panic/oops message is sure better than a silent hang, but >> that's it, really. >> Anything less than that should just go in a logfile where the admin >> can look >> it up later. The very ability to write on the console will alway be >> abused >> by some application programmer or kernel driver module vendor. >> Blindly writing on the console won't be very useful either, the user >> might >> be running a game or video which overwrites the message within 1/30s >> anyway. >> Well, perhaps it can be done better than that, with some thought. I.e. : >> >> * block all further access to /dev/fb0, processes will wait. >> * Mark graphichs memory "not present" for any process that have it >> mapped, >> so as to pagefault anyone using it directly. (read-only is not >> enough, >> processes should see the graphichs memory they expect, not >> the kernel message) >> * Try to allocate memory for saving the screen image (assuming the >> machine won't hang completely, it will often keep running after an >> oops) >> * Annoy the user by showing the message >> * Provide some way of letting the user decide when to proceed, such >> as pressing a key >> * Restore the saved screen memory (if that allocation was successful) >> * Mark framebuffer memory present, releasing pagefaulted processes >> * Unblock /dev/fb0 > > Still too complex. Sure - which is why I sort of hope it won't happen. > Can't this be simplified to: > > * Don't use the kernel text output facility for anything except > panics, where there is no point in allowing userspace applications to > continue That's an option, of course. > * Rely on userspace to display oopses and less important messages, > because doing this from the kernel leads either to the complex > procedure outlined above (where the policy is in the kernel, e.g., on > which of the two keyboards should one wait for a keypress?) or to > unreliable displaying of messages "Which of the two keyboards to read, which of the three screens to use for messages" is not a problem. The kernel would use whatever devices is associated with the primary console - any extra devices would be left alone. The console is normally one particular keyboard (or possibly all of them), and /dev/fb0 in case of graphical console. Other framebuffers are not the primary console.
Someone with a network console or printer console should get their message there instead - assuming the subsystems in question still works.
> * Have a method in the framebuffer driver for clearing the screen and > setting a known good mode, for the Linux equivalent of a "blue screen > of death" Those are there already, if you're using a framebuffer device driver that is.
Helge Hafting
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |