lkml.org 
[lkml]   [1998]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: kill -9 <pid of X>
On Sun, 16 Aug 1998, Brandon S. Allbery KF8NH wrote:

> In message <199808162128.RAA29107@jupiter.cs.uml.edu>, "Albert D. Cahalan"
> writ
> es:
> +-----
> | Jes Sorensen writes:
> | > drivers. You have been told a million times here that acceleration
> | > belongs in user space and still you insist on putting it in the
> | > kernel where it does not belong.
> |
> | Shut up, you elitist 680x0 user.
> +--->8
>
> My, such a cogent argument. Guess we all better fold up and hand the kernel
> over to you so you can move everything into the kernel.
>
> (I'm an x86 user, by the way, so your ultimate argument doesn't apply.

The point being made is this:

Fast acceleration (with new x86 hardware): Must be done in kernel.
Normal Accelleration: Must be in kernel or have raw hardware access.
Dumb frame buffer: Raw hardware or in kernel.
Run safely: Must not be in userspace.

This situation is not likely to change and will get worse..
Kgicon does a VERY good job, go download it and spend a week getting it to
work.. :)

You have the system boot up with either text mode (or if text mode isn't
possible) something like vesa FB (a dumb frame buffer).. Then after it's
up the approiate video module gets loaded and apps have safe access to
fast acceleration.

Minimal kernel bloat. I think the interface for kgicon should be in the
standard kernel, and the dumb devices (for bootup should be there).. The
accelerated drivers should be a seperatly maintained package.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.038 / U:0.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site