lkml.org 
[lkml]   [2006]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: OpenGL-based framebuffer concepts
Date
On Wednesday 24 May 2006 13:55, 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. 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
> * 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
> * 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"

Exactly - this is what I had planned on doing. Let userspace handle all other
types of errors, as a panic is the only thing that should leave the kernel
itself unstable.

The setting of a "known good" mode is also simple - just swap the card back to
the boot video mode and clear the screen.

DRH
-
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/

\
 
 \ /
  Last update: 2006-05-25 04:08    [W:0.332 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site