Messages in this thread | | | Date | Fri, 2 Jun 2006 09:14:41 +1000 | From | "Dave Airlie" <> | Subject | Re: OpenGL-based framebuffer concepts |
| |
\ > 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.
Jon stop trying to hammer everyone by repeating ad-nauseum statements of little importance...
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..
The same things apples to a lot of your other "issues" a /dev/ with permissions is no more or less useful than a /tmp/.grphs_socket1 and 2 with permissions, you insistence that everything be controlled via the kernel is another thing you've just failed to think about rather than hammer on about it *must* do this.
I'm spending more time rebutting points you repeatedly make, please accept that there are other solutions, and everytime you post a list of things *YOU* believe *MUST* be done, remove the things we've shown are possible to be done other ways...
Dave. - 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/
| |