lkml.org 
[lkml]   [2006]   [May]   [26]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateFri, 26 May 2006 09:08:01 +0200
FromHelge Hafting <>
SubjectRe: 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/

\
 
 \ /
  Last update: 2006-05-26 07:13    [from the cache]
©2003-2008