Messages in this thread | | | Date | Thu, 1 Jun 2006 16:35:12 -0400 | From | "Jon Smirl" <> | Subject | Re: OpenGL-based framebuffer concepts |
| |
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/
| |