Re: OpenGL-based framebuffer concepts

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

On 6/1/06, Dave Airlie <airlied@gmail.com> wrote:
> We can stop the OOM killer from killing the daemon if necessary.
> running device drivers in userspace would sort of require this, we can
> run the daemon from init and if it dies, have it respawn, it could put
> persistent info in a shared memory segment provided by the DRM, just
> because you can't think of any way around things, doesn't mean the
> rest of us can't..
>
> a /dev/ with permissions is no more or less useful than a
> /tmp/.grphs_socket1 and 2
> with permissions,

/dev/devices have a standard system design in the kernel with h files
and ioctls. Why create a new communication protocol when a standard
one exists? How is a printk generated in the kernel going to find this
socket and get the printk message into it?

You have a panic in an interrupt handler. User space is messed up
because of wild pointer writes in the kernel. Your display process has
been swapped out. How are you going to display the panic message?

How does a process protected from the OOM killer that is also pinned
into memory differ from just being part of the kernel? Is creating a
process like this and building a communication system worth it just to
get address space separation?

Why don't you write up a comprehensive design for your system and post
it for all to read. It is difficult to piece together an overall
picture from 100s of emails talking about specific features. To do
this right  you have to address everything from fbdev to X to SDL to
i8n. There were 13 design requirements posted earlier, can your system
satisfy all of those?

Any designs you propose have to be able to stand up to questioning
like this. It is much better to deal with the problems as questions
rather than to find them after the code is written.

-- 
Jon Smirl
jonsmirl@gmail.com