lkml.org 
[lkml]   [2006]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: OpenGL-based framebuffer concepts
Date
> One solution to this split is to build the system management console
> in-kernel using the existing fbdev code. A hot key can be used to
> access it or it will appear automatically on a panic. The system
> management console does not need acceleration, but it always has to
> work and work in any context (like interrupt context). Working in any
> context forces an implementation that is entirely contained in the
> kernel.

And what happens if that console data has been damaged by a wild pointer write
in kernel?

This does have a practicle use, and the console data for the "System Console"
is unlikely to get screwed with. I am just pointing out that there are
problems even with your suggestions. I had already planned on something
similar to this when I began working on a method to have the video drivers
able to be added and removed at runtime. What I was planning on was using
vgacon (for those systems that support it) as the system console and having
tthe system default back to that should *anything* go wrong in the kernel.
For the systems that don't support vgacon there is going to be a very minimal
fbcon that will serve the same purpose.

Userspace helpers for modesetting and other simple tasks is no problem. When
it comes to handling the acceleration, the DRI part of the DRM
infrastructure (the Userspace side of it, in other words) needs to be running
and available. This is why X has to load the module. Providing that to
userspace then become a concern, and the easiest way to do this is to have
the DRI portion loaded and running inside a userspace daemon, either pinned
into memory so that the OOM killer can't touch it, or running as a special
process under init that will *always* get restarted if it dies.

Using a mass of userspace helpers, or requiring the applications to provide
and load their own userspace drivers for the DRM/DRI system is, IMHO, not an
option.

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-06-02 04:25    [W:1.144 / U:0.940 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site