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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
