From: MenTaLguY <mentalg@geocities.com>
  To  : ggi-develop@eskimo.com
  Date: Thu, 20 Aug 1998 20:36:35 -0500 (EST)

Re: LibGGI3D RFC

On Thu, 20 Aug 1998, Olivier Galibert wrote:

> On Wed, Aug 19, 1998 at 03:50:34PM -0700, Jon M. Taylor wrote:
> > 	KGI drivers should support whatever the hardware supports.  If the
> > hardware supports triangle sets, so should the KGI driver.
> 
> Hmmm, may I  amend this sentence?  I'd  rewrite it as "The  KGI driver
> should  support whatever  the  hardware supports   and  that cannot be
> handled safely and efficiently in userspace".  Do you agree?

Indeed.  Really, everything that can go in userspace should go in userspace
-- that is, if it can be done securely (i.e. KGI can still
save/restore/reset the state cleanly, and there is no way to lock up the
machine or anything).  For some well-designed hardware, it would not be
unreasonable to just MMAP many of the io ports through to the userspace side
of things, more or less like the stock fbcon drivers tend to do for most
everything.

Remember, we're only in the kernel so that we can effectively arbitrate
access to the hardware and protect from malicious software (which,
obviously, are the two biggest failings of suid userspace approaches).  As
long as the kernel can really stay on top of things while shoving many of
the MMIOed registers into userspace, may as well implement the accels you
can in userspace, instead of adding a special ioctl() (well, command,
anyway) for each. 

Granted, most hardware isn't well-designed enough to allow that approach and
remain secure, but it's not impossible.  It would be good not to forget that
where it can be made secure, it is more desirable than necessarily having
specific support in the KGI driver for every feature. 

-=MenTaLguY=-