From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Mon, 22 Feb 1999 15:03:46 -0800 (PST)

Re: RFC: Abstract register handling in KGI

On Mon, 22 Feb 1999, Steffen Seeger wrote:

> Hi Jon,
> 
> This is just to indicate I have received your two RFCs/mails.
> 
> I will have a close look at them, but response time may be one/two days.
> I am moving into a new flat, and need to do some realworld painting/
> non-KGI related (physical work).

	I am also moving soon (Sunday probably).
 
> As for the includes, as far as the 3Dlabs driver goes, they are just an 
> artefact, and I was too lazy to clean them up.

	Sure.  And that is strictly a driver-internal issue, no need to
bloat the KGI spec with this stuff.
 
> As for the module in general, the reason I explained last time still holds.
> I need a mechanism to keep things 'static' (module internal) on a object
> level, but want to share the code for this over several modules.
> This can't be done by linker tricks on all possible architectures, and thus
> I have chosen to put them in special files that ain't module interface
> definitions...
> 
> Could you please forgive my ignorance and give me [again] reasons why 
> they are so bad?

* Nonstandard and thus confusing
* Turns the .inc files into messes of #ifdefs
* The current Matrox KGI driver does it correctly and it works fine
* Libtool is suppsed to be able to take care of all this cross-platform

	That having been said, .inc files are not the most evil thing in
the world.  They do work.  But they should not be used unless there really
is no other way.  That may have been true in 1996 when you first wrote
KGI, but I do not think it is true anymore.  Take a look at the Matrox 
(chipset) drivers in CVS and tell me what you think.
 
> As for the I/O scheme, here is an old posting of mine you might remember.
> Perhaps we should merge this/take the best of both worlds...
> 
> >  - I2C interfacing
> > 
> >    It's a serial bus used to talk to digitizers and other add-on
> >    products. add-on products need a way to do this independent of the
> >    graphics chip. In fact this is very much like the "outsbDDC"
> >    "insbDDC" concept. (No MS standard, hopefully someday)
> 
> I2C is fairly standard in electronics industry. However, there will always be
> other interfacing techniques that we could not even know of now. So what I
> think what is actually needed is a kind of I/O address space 'filesystem' in 
> the kernel (or a address space server for microkernels). 

[snip]

	An OS guru whom I worked with at NEC called this type of idea a 
'vnode' interface.  Basically you attach a new virtual filesystem at each 
point where you want a custom interface, and do all your device I/O 
through the filesystem.  GGI console takes this approach.  However, IMHO 
this is unsuitable for raw register I/O for two reasons:

* No code outside the driver should be doing raw register I/O for safety
reasons.  Thus, there is no reason to go to the trouble of building a
file-based I/O layer, which can only slow things down.  The driver should
be opaque to userspace except for mmap()ed framebuffer access and 
ioctls/sysctls.

* By using such a layer, the entire register layout is exposed to 
userspace for anyone to see.  This defeats the purpose of binary-only 
drivers - to hide the hardware layout from prying eyes.  No company which 
wants to protects its hardware specs could use such a system.

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