In message <4.2.0.58.19991118213339.00a20340@3am-software.com>,
Matt Thomas writes:

>I really want to see ibus moved out of pmax/ and under /dev (perhaps
>putting making it dbus).  I think that the ibus device attachments 
>should be common with the vax port.  the dc/dz for instance.  any
>wscons support should be port neutral.  

That doesnt actually make much sense.  The "ibus" wsa supposed
to  be an `internal bus'  onto which to attach PMAX (2100, 3100)
baseboard devices.  The 5100 fell out `for free'.

If you look hard at the dcxxx chips in uvax &c, you'll find that the
dz device registers don't have the padding that the dc (pmax) devices
have. So they ned either separate drivers, or a level of indirection.
Ragge looked at the code and decided that the extra level
of indirection wasn't worth the cost.

The killer is that Qbus (or Unibus) mips systems would need the
non-padded driver as well....

Does the sii in vaxes have the same funky 16-bit padding as on pmaxes?

>This will also help the ds5400/5500 to leverage the vax q22bus support,
>shac, and other devices.  imagine running X on a QDSS(GPX) on a 5400.

Leverage, yes, but I dont see how that helps. The right way to do Qbus is
via chipsets.  If we call the Mayfair Q22 chipset, say, mayfair
(I'm sure there's a better name) we could have
	mayfair* at mainbus0
	uba* at mayfair?

and put the smartsa bout mainbus location of the mapping registers,
their format, &c, into a `mayfair' module, we could use it on any
machine with a microvax 3900-style Qbus adaptor.
Last I looked that was all intertwined with cvax goo.


I looked at the SGEC docs, tand the native `vax' mode reads vax ptes
and follows them. If the vax driver uses that, we'd need a completely
different strategy for bus_dma on mipsel.

(Imagine? Some of us are trying to forget. No, that was qvss..)