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

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/

\
 
 \ /
  Last update: 2006-06-02 01:17    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site