Index:
[thread]
[date]
[subject]
[author]
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
Index:
[thread]
[date]
[subject]
[author]