[lkml]   [2006]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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...

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-06-02 01:17    [W:0.266 / U:9.268 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site