Within a few days I'll check in "phase I" of the device auto configuration
changes I mentioned some time ago.

"Phase I" will deal with device declarations in `files.sparc' and
changes in the bus attach arguments. In general, driver match/attach
code becomes simpler because the auto configuration code is sorting
out more things for us, but the actual size of the code has increased
in most cases since there's now a pair of match/attach function for
each bus a given device can attach to (the pack is headed by the `le'
device that attaches to four busses..). Also, some code duplication
seemed unavoidable in places.

I've run the new code on a sun4c and sun4m machine. If there any
volunteers willing to test the sun4 code, please contact me to work
out the bugs.

BTW. "phase II" will someday cover bus_dma(9) changes.

-pk


Re:
> I'm making the sparc sbus/obio drivers fit the bus_space(9)/bus_dma(9) model.
> Hopefully, this will result in those drivers being far less dependent
> on cpu archicture quirks, so for instance, someone doing an ultrasparc
> port needn't worry about adapting sbus drivers (too much..).
> It also might result in code shareable with the sun3/sun3x.
> 
> The approach I'm taking is this:
> 
> 	- all drivers that attach to multiple busses now will get
> 	  split attachment routines, e.g.:
> 
> 		attach <device> at sbus with <device>_sbus
> 		attach <device> at obio with <device>_obio
> 
> 	- each bus (sbus, sun4/obio, sun4m/obio, sun4c/mainbus) will
> 	  have its own attach arguments in stead of the Grand Union
> 	  `confargs' we have now (it used to be more or less like this
> 	   before the sun4 code got merged in many moons ago)
> 
> 	- each bus will export bus map functions (e.g sbus_bus_map())
> 	  and DMA handling routines, per `bus_{space,dma}(9)'
> 	  Note that in sbus drivers I'm currently not using the bus
> 	  map macros defines in bus_space(9) directly, since device
> 	  I/O space addresses do not smoothly fit an integral `bus_addr_t'.
>