lkml.org 
[lkml]   [2006]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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 09:13    [W:5.335 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site