Re: OpenGL-based framebuffer concepts

["D. Hazelton" <dhazelton@enter.net>]

On Thursday 01 June 2006 20:35, Jon Smirl wrote:
> 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.

Yes, the basic console will only require a few helpers. I get "tons" because 
that's what it would take to provide all the acceleration features to 
userspace. The daemon is *only* there to provide those acceleration features. 
The kernel itself has it's own minimal interface to drmcon that lets it work 
without userspace. The userspace side is for userspace. (Though the kernel 
will only work in a specific set mode without the userspace helpers for 
setting the mode)

Cursor control will be entirely within the driver :)

> > 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.

Hrm... I was thinking that it didn't work for sending to net and serial 
consoles because doing such might generate an interrupt.

> > > > 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.

Of course. It is one of my goals to keep those silent deaths from occuring. 
AAMOF, that was one of my reasons for this project.

DRH