Re: OpenGL-based framebuffer concepts

["Jon Smirl" <jonsmirl@gmail.com>]

On 6/1/06, D. Hazelton <dhazelton@enter.net> wrote:
> > > 5) The system needs to be robust. Daemons can be killed by the OOM
> > > mechanism, you don't want to lose your console in the middle of trying
> > > to fix a problem. This also means that you have to be able to display
> > > printk's from inside interrupt handles.
>
> Point of disagreement. Tons of userspace helpers isn't a good choice.

Where do you get 'tons'? There will probably be one for initial reset,
one for VESA based mode setting and a few more if there is device
specific code needed for a specific card.

Making console rely on a permanent daemon that is subject to getting
killed by the OOM mechanism is not a workable solution.

You also need to think about how cursors are handled. A non-root app
needs to be able to move the cursor. Actually moving the cursor
requires root. The in-kernel console system needs a cursor. It would
be much better if cursor control was implemented in the device
drivers.

> I don't know about doing a printk from inside interrupt context - the current
> architecture doesn't, IIRC, support printk from inside interrupt context for
> certain drivers for various reasons.

Printk works from inside interrupt handlers currently. This is an
absolute requirement for kernel debugging that can't be removed.
Because of this requirement there has to be a way for all drivers to
draw the console entirely inside the kernel. You can not make calls to
user space from inside interrupt handlers.

> > > 6) Things like panics should be visible no matter what is running. No
> > > more silent deaths.

Panics can occur inside interrupt handlers. You can't queue up printks
in this context and they display them later, the kernel just died,
there is no later.

--
Jon Smirl
jonsmirl@gmail.com
-
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/