[lkml]   [1996]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: SVGA kernel chipset drivers.

    the following discussion is only true if GX >register< access times are an
    issue. And judjung from the X server using iopl(), it's an issue ...

    On Sun, 2 Jun 1996, Linus Torvalds wrote:

    [ "priviledge dropping" SVGA server implementation in user space ]

    > Essentially, this already sets up the protection domains. The server is
    > protected, yet the fork() inheritance is able to give the graphics
    > program all the resources it needs, and nothing more.

    presuming that a user program is allowed to have all priviledges. What we
    are talking about is an interface to the graphics hardware. The direct
    method is the way X does it: it gets the whole resource, on "bare metal"
    level. On the other hand, the most indirect way is having everything that
    does a single outb() or similar operation, in the kernel.

    The problem is not the framebuffer. The problem is those zillion
    VGA/SVGA/XGA/CGA/EGA/S3/Mach32/64/etc registers that all need to be put
    straight. In userspace either we use iopl() to get >all< registers on the
    machine, or we use ioperm(), to get some registers (but we have to take
    the performance hit on a >per register basis<.

    With a "partly in the kernel" approach, the performance hit is per
    operation. I dont know all GX cards that well that i could decide which
    performance hit is bigger. But what if we dont even want to give register
    access to a user program. I'm not trying to be destructive or anything,
    just imagine that some cards are capable of damaging some older monitors
    with too high frequencies. Some cards burn if they get programmed to a too
    high clock rate. I think some cards cant be recovered to text-mode, if the
    access to the registers is not traced in a secure way. These problems
    can't be solved with the ioperm() call.

    the X way is a very good solution, once all clients are communicating
    through a high-level graphics protocol (read: X protocol). No problem
    taking the IPC hit, unix-domain sockets are fast as hell anyways. But the
    ususal SVGA programs have much lower level operations (changing the
    palette using some registers that btw. might be right next to the clock
    generator registers) to make an IPC viable.

    In this sense we can talk about X as the "X protocol kernel".

    I know the whole concept of PC graphics cards is broken beyond
    recognition, but at least we have to understand the problems before
    talking about the solution :) [i'm afraid that it is me who should start
    doing so]

    -- mingo

    ps. i like the user space solution much better, since it's much more
    robust. but the problem is that for >any< >safe< interface we want to
    impelement we have two choices currently:

    - using some kind of IPC: TLB flush and >5 usecs switch time
    - using a kernel trap: 2.5 usecs enter/exit time

    there are other possibilities:

    - maybe using call gates to ring 2 or ring 1 ... dunno how, and it breaks
    on other platforms i guess

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