> 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 finale driver:

	include		Driver interface headers, chipset register definitions.

	kernel		The kernel interface, memory mapping and console 
			handling. We may need to define an additional
			kgi_Chipset routine that allows/handles VRAM mapping.
> 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
	[...]			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. We can provide a configuration tool later
			if there are lots of drivers. Note that this does not
			depend on having the sources of the several parts.
			Thus we allow for commercial drivers distributed in 
			binary format.
	.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 (DAC, clock, chipset or 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.

   2)	Create a Makefile in that directory you've added. This does mainly need
	to list the supported chips. (I've choosen the manufacturers part ID
	as this will be unique.) This name gives a new ???_CLASS in .config.

   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.

   4)	To 'use' this driver, modify .config appropriately and recompile.

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