From: Brian Julin <bri@forcade.calyx.net>
  To  : ggi-develop@eskimo.com
  Date: Wed, 12 Aug 1998 08:40:19 -0400 (EDT)

Re: kgicon FAQ

On Tue, 11 Aug 1998, Jon M. Taylor wrote:
> 	If you keep your drivers monolithic, they will degenerate over
> time into an unreadable mess of #if blocks and special cases.  This is
> exactly what has happened to the XFree86 drivers.  In contrast, with a KGI
> driver the interfaces are clean and everyone knows what subsections are
> responsible for what tasks/info.  It isn't perfect, of course; IMHO, the
> chipset driver is still too monolithic.  Hardware detection and
> initialization and IO methods should be broken out into their own driver
> subsections.  One thing we need to work on is how we implement our driver
> modularity.  Except for the Matrox drivers, right now all the KGI drivers
> use .inc files for common code, which just swaps the code in using
> #includes.  This is bad.  Hopefully all this will be cleaned up during the
> move to Degas-KGI.

I have started to do link-time inclusinon if parts of my chipset
driver in the new WD code.  Right now it uses an autogenerated C 
file.  I can include support for one or more of the chipset
models and the main driver code will find them by strolling through
a global linked list of function tables which the objects attached.

Of course I'd prefer not to autogenerate a C file and insert the model
code through some sort of symbol manipulation with the linker,
but I'm not that good with linkers.  I can commit this (it's not
functional except for the code loading part and parts of the
detection code) if you want to look it over and size it up.

--
Brian S. Julin