>       This is one of the reasons why the 3D hardware support must be into
> the kernel (of course, the main one is that "it's hardware, you shouldn't
> talk directly to the hw on a unix machine!!").

> >     Isn't hurt by input or other processing/signals/...
>       My opinion is that it's more usefull, interesting and important to
> have the stuff that you want to put on this server, into the kernel, at
> least partially, and If i'm right it's what is being done with KGI... It
> doesn't crashes the hardware, it doesn't have security problems, it can
> avoid easily multiple tasks accessing to the hardware, and assign the
> display to the focused one (the one that is on the current console), etc.
>       How can you control from this server which task should show it's
> graphics and which one you should ignore commands from?
>       From the kernel, instead, it's very easy...
>       My opinion is this, let the kernel do it's work (avoid tasks
> problems, security problems, hardware abstraction, etc.) and use servers for
> the things that they should be used (of course, neither hardware
> abstraction, nor tasks controlling, I hate X-Window system design, most of
> it should be at the kernel).

For sane hardware you can allow a process to talk to video hardware. The
kernels job is to ensure proper virtualization. With proper virtualization
security and stability come naturally. Now for low end hardware you really
can't have direct rendering. 

> > Oh, and one last point.  Communications between threads or processes is
> > evil.  Really evil.  Case in point : locking of shared data within the

I seen alot of talks about threads. In linux threads are lightweight
processes, meaning they share the same page tables. So to maximize your
threads you want to create a bunch of threads that share read only data in
memory. A good example would be a static vertex list. You can also write
to this memory but then the OS has to sync up the cache for all the CPUs.
Threads are also good when you have alot of process waiting for I/O

Codito, ergo sum - "I code, therefore I am"
James Simmons                                                      (o_
fbdev/gfx developer                                      (o_  (o_ //\
http://www.linux-fbdev.org                              (/)_ (/)_ V_/_

Reply via email to