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 [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]
