Re: OpenGL-based framebuffer concepts

[Pavel Machek]

On Ät 01-06-06 20:45:20, Jon Smirl wrote:
> On 6/1/06, Dave Airlie <airlied@xxxxxxxxx> 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?

Well, daemon vs. standalone binaries make no difference here.

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

Yes, certainly it is worth it. And remember you'd have to protect your
small helpers, too, OOM can happen there.

Daemon is the way to go, sorry.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/