From: Olivier Galibert <galibert@pobox.com>
  To  : ggi-develop@eskimo.com
  Date: Sun, 23 Aug 1998 04:07:03 +0200

Re: Can I do that ?

On Fri, Aug 21, 1998 at 03:03:55PM -0700, Jon M. Taylor wrote:
> On Fri, 21 Aug 1998, Marcus Sundberg wrote:
> > I think what he meant is that a KGI driver should be accompanied by
> > a special libbggi driver-library that is optimized for that driver.
> 
> 	IMHO this is a bad idea.  LibGGI is NOT the only userspace
> library/platform which can have KGI-using driver-libraries.  Suppose
> someday XGGI, Mesa, Berlin, DirectX, LibGGI2D, LibGGI3D, LibGWT and God
> only knows how many more have their own specialized driver-libs.  Should
> we include *all* of them with the KGI drivers?  And there is another
> issue, too.  If we ever expect to get into the kernel, we can't have KGI
> drivers dragging around userspace code.  I guarantee you Linus won't
> accept that.  Package the driver-libs with the userspace code that uses
> them.

When is the lastest time you used syscall()  directly instead of going
thru the libc?

libggi/ggi2d/ggi3d are the  equivalent of the  libc.   They present to
mere mortals   (i.e.   higher  level  libraries  or  applications) the
semantics the kernel interface gives.  XGGI, Mesa, Berlin, DirectX and
GWT[1] should *never*  *ever* go to  the KGI driver directly, for  the
same reason than programs and libraries use open() and not syscall(5).

Now, if you  want to do a *really*  accelerated KGI driver for a card,
you need   a specific libggi*<->kernel   interaction.   This means the
kernel side of the driver is tied to the user side.  The KGI interface
is something fuzzy which is going to  change a *lot* through time, and
probably in  a card-specific way.  Hence, each  time you release a KGI
driver, you're  going to have to  release  the card-specific subset of
all ggi* libs too.  And the release cycle  of said drivers is going to
be independant from the release cycle of the full libs.

Actually,  the full libs define  the  API and a default implementation
which  probably   goes  all the  way     to dumb  framebuffers.    The
driver-specific   additions plug in   that   to use  the card-specific
accelerations.  Because  of the plugging   system you can upgrade  the
full libs independantly   from  the card-specific  addons.   You can't
upgrade  the card-specific   addons independently from  the associated
kernel-level driver.

BTW, the kernel drags  around a  *lot*  of userspace code.  The  libc,
init, fsck, *mount,  shutdown, cyrix utilities... comes  to mind.  And
there were a lot more before the advent of /proc.

  OG.

[1]  Is  there any  hardware out  there  that  provides functionnality
implemented in gwt?