From: Brian Julin <bri@forcade.calyx.net>
  To  : ggi-develop@eskimo.com
  Date: Sun, 21 Feb 1999 10:54:30 -0500 (EST)

Re: RFC: Abstract register handling in KGI

I had similar thoughts when I started writing a KGI driver.
But the complex scheme of interlocks in the wd90cxx series 
(over 30 registers that can lock or alter other registers
behavior) would have made it a real chore to actually make the data 
hierarchal.  I think some sort of way of handling blocks
of similar registers would be good, but perhaps not as 
finely grained and descriptive a structure as you are proposing.

I totally agree that register state needs to be stored in a 
consistant fashion from one driver to another.  Also for example,
the current handling of things like CLK_out8 would benefit a lot
from what you propose, and allow for better support of multiple 
adaptors -- instead of linking a symbol the clock driver should receive
a pointer to a function to store (or queue for storage during a full register
store operation) by the chipset.  That function pointer would come in a 
structure that allowed the chipset driver to know what card the clock in 
question was on, and the structure would be passed back to the chipset driver
when it was called.  That way the clock driver would be able to alter
either the hardware state or the stored state for a mode, and 
mode calculation could occur on a vc when it is not focused and
using a memory visual.

The intra-module API definitely needs enhancement. I'm just not sure if 
a fully "abstract" system is entirely practical.  Storing the data 
in a whole new layout (e.g. metaregisters) inside the driver as opposed 
to something roughly similar to the actual hardware layout adds a level
of complexity that might actually hinder people from understanding 
another person's KGI driver, and might overwhelm new developers.  
Something a little more simple that is flexible enough to allow a few 
hacks where it is necessary to tuck corners might be a better course 
of action -- perhaps even just a set of guidelines rather than a system 
of code.

--
P.C.M.C.I.A. stands for "Plastic Connectors May Crack If Adjusted"
                                                             -- me
--
Brian S. Julin