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

    > In message <>, "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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:44    [W:0.024 / U:1.048 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site