From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : GGI mailing list <ggi-develop@eskimo.com>
  Date: Thu, 25 Feb 1999 01:26:41 -0800 (PST)

Driver internal structure

	So how do we break it up?  Right now we have chipset, ramdac, 
clockchip, and accel drivers there.  but we also have sub-options within 
some of those categories:

* Chipset: I/O methods, target OS
* Ramdac: STREAMS, TV tuners
* Clock: Not much here actually
* Accel: 2D/3D

so we need a new structure in the config system to properly handle this. 
The new KGI has the I/O methods and target OS split off from the chipset
driver into a 'System' driver, which is OK.  But we should really have a
generic extension system in place, similar to LibGGI.  API extension and
overloading through modules loaded into the kernel, same as LibGGI loads
its .so files, with demand loading throught kmod.  A system like that
would cut throught the current KGI chaos, sames as it did when
LibGGI-dynamic came out.  It facilitates fine-grained modularization and
code re-use, is easier to follow, and is a **LOT** easier to code in.  But
can it be done?  Can it be done cross-platform, on systems without 
modules as well?  I don't know.  Anyone?

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed