> I haven taken Steffen's attempt to separate the several driver components.
> Except for the "> indented" comment this is his README.

The several subdirectories will hold parts of the final driver:

	include		Driver interface headers, chipset register definitions.

	kernel		The kernel interface, memory mapping and console 
			handling. We may need to define an additionali
			kgi_chipset routine that allows/handles video RAM
			(re)mapping/paging.

> Yes - there may be many other things that have to be modified in the
> interface for every driver, if we want to keep really fast. For this reason I
> did not implement this up to now - I may be persuaded though, as performance
> is not too critical for me ... for now this remains in the chip-driver.

	monitor		Monitor drivers
	monitor/mulisync	Mulitsync drivers.
	[...]			others may follow, see below.
	
	ramdac		RAMDAC drivers [Other ideas for classification ???]
	ramdac/ATT		drivers for ATT DAC's
	[...]			others may follow, see below.

	clock		Clock chip drivers.
	clock/programmable	programable clock devices, such as icd2061a
	clock/fixed		clock chips with fixed clock rates 
	[...]			others may follow, see below.

	chipset		Chipset drivers
	chipset/S3		S3 chipset drivers.
	[...]			others may follow.

This provides an extendible structure to maintain more than one driver. The
makefiles rely on several files to be in the driver/ directory.  These are 

	.config		Driver configuration, at the moment mainly a hardware
			description. This file will be deleted after doing
			`make distclean`. If it is not present, the configure 
			script will be invoked to create it. 
			Note that this does not depend on having the sources
			of the several parts. Thus we allow for commercial
			drivers distributed in binary format (If that may 
			happen one day...;-)
	.recursive	common targets (clean, distclean, etc.) for recursive
			makefiles (makefiles in the subdirs except 
			driver/include/ )
	.non_recursive	common targets for non-recursive makefiles.
	.make_rules	implicit rules used for compilations, etc.

If you want to add a hardware driver it could be done very easy:

   1)	If you have to add a new architecture (ramdac, clock, chipset or i
	monitor) create a new subdir in the appropriate driver part subdir and
	update the SUBDIRS variable in Makefile. This is enough to make make 
	take care. Then add an suitable menu item in the .configure script.

   2)	Create a Makefile in that directory you've added. This does mainly need
	to list the main source file to compile to get the driver binary object
	file. All other dependencies are maintained automatically. (I've choosen
	the manufacturers part ID as this will be unique.) This name gives a new 
	???_CLASS in .config. There are preedited makefiles in the .stubs/ 
	directory as well as a stub .configure script. You may copy these and 
	insert the neccessary lines. 

   3)	Write the driver. Take care to declare functions and variables static
	to avoid conflict with other driver parts. The driver must compile into
	and [chip].o file, this name gives a new possible ???_TYPE in .config.
	The only dependencies (in compiled form) to other driver parts are the 
	data structures and functions declared in include/ggi.h and 
	include/kgi.h. Thus direct I/O is only allowed for the chipset driver.
	The others have to stick to the generalized functions. 

   4)	To 'use' this driver, modify the .configure script appropriately so 
	that you will be able to choose this driver from the menu. 
	Then reconfigure either by editing .config or by invoking `make config`
	and rebuild the driver.

I will maintain this driver directory for a while, depending on the time I
am able and willing to spend on it. 

			Steffen

[Steffen Seeger, seeger@physik.tu-chemnitz.de]
