lkml.org 
[lkml]   [1998]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: GGI, EGCS/PGCC, Kernel source
    From
    Date
    >>>>> "linker" ==   <linker@nightshade.ml.org> writes:

    linker> I agree that GGI seems a bit 'bulkey' but it's obvious (from
    linker> looking at their snapshots) that they have done TONS of work
    linker> to make it as small and clean as possible.

    linker> Part of the reason it's so complicated is because of all the
    linker> things it does.. I really dont think that it's anymore
    linker> complicated then the network subsytem.

    Well the network subsystem is allowed to be complex because the
    protocol handling is complex, it is not necessarily the same for a
    graphics subsystem.

    linker> Here are some of the things they are shooting at..

    linker> *Output device abstraction *Input device independence
    linker> *Platform indepence *Kernel Level Hardware control (most
    linker> IMPORTANT part.. IHMO )

    Well you cannot make 100% abstraction inside the kernel without making
    things bloated _and_ slow. This discussion has been at linux-kernel
    before, however basically a kernel graphics abstrction interface needs
    to be able to set the video modes and run some sort of console,
    ie. for framebuffer consoles it makes sense to use an optional blitter
    for scrolling and clearing the screen, ie. the functions necessary to
    make the console fast and nothing else. Anything that needs to run in
    graphics mode such as X, svgalib and similar apps. should deal with
    this in user space to achive maximum performance. The kernel interface
    should not in any way provide a generic blitter interface or anything
    like that, but I don't think the GGI guys are trying to do that
    anymore.

    linker> *Mutiple input/output devices

    Hounestly I don't see the need for connecting 7 keyboards and monitors
    to a PC.

    linker> *Multihead from the consol level up..

    fbdev does this already.

    linger> *High performance

    Well this might be better now, but back when Geert tried to port the
    GGI console to the m68k `performance' was not on the list of words
    describing the result. Of course things may have improved a lot here.

    linker> *Access to fancy hardware features (this is tough when you
    linker> consider they are trying to be abstract)

    Again, it is very important to consider what actually needs to go into
    the kernel and what should and can be kept in user space.

    linker> Can you think of a better way of say poping in two pci video
    linker> cards and two keyboards (one on the ps2mouse port) and two
    linker> mice and having a single computer act as two for all apps in a
    linker> transparent way?

    Do we need this, do anybody actually want this?

    Besides fbdev handles multiple consoles on arbitrary devices, the only
    thing you need to add is multiple keyboard support.

    Again, I am not fully uptodate on GGI, a lot of the things in GGI are
    most likely done the right way. What I am after is just that we should
    keep things simple, and only put the necessary things into the kernel.

    Jes

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu

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