From: Andreas Beck <becka@rz.uni-duesseldorf.de>
  To  : ggi-develop@eskimo.com
  Date: Thu, 5 Aug 1999 21:05:38 +0200

Re: Matrox GGI accellerator

> > The bottleneck here is the translation from kgicommands to hardware
> > commands/register writes.  This is why it is _critical_ that the kgicommand
> > interface for a particular KGI driver be able to map closely to the actual
> > hardware command structure, and that the userspace GGI target code can not
> > assume that there will be some kind of generic kgicommands which exist across
> > all drivers.

> Do you have an idea on how to define such 'kgicommands' language ?

This basically exists. Note, that the KGI drivers export a kgi-command
interface, not an ioctl interface. It is the OS glue layer, that translates
ioctl->kgicommand. It can as well translate pingpongbuffer->kgicommands.

> If we want something rather generic, the driver will need to _interpret_
> the command (which may slow him - but I'm not sure it would
> be so slow: the commands are pretty simple). [I'd favour this.]

The commands need to be interpreted _somewhere_. Doing that in kernel or
userspace is not a performance issue. It is just an issue of kernel module
size and thus to some extent of stability, as a buggy kernel module is more
serious than a buggy userspace module.

We can have both at the same time BTW.

> If we want something flexible, a userspace lib can simply write
> the _real_ display list commands directly into a buffer given
> to the kernel driver - the the driver 'only' needs to _validate_
> them (by checking there are no false command code, etc.)

That would be wasting CPU. The userspace code already interpreted them,
and then we validate them again. 

This could be done, if validation is cheap, security is important and
kernel module size should be kept low.

CU, ANdy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =