I've been focused on the i386 and Alpha ports (with a little pmax port)
until now.  But now I have two VAXes, a VS4000/60 and a uVAX I (yes, one).
Though I'm going to ignore the uVAX I for now.

I'm adding on focusing the VS4000/60 and getting its SCSI and Sound
ports working.  It would make my life easier if the VAX port was 
closer to other ports in some respects.

1) It may seem trivial but it would be nice instead of backplane0,
   mainbus0 was used (like most other ports).  Mostly for consistency
   but also because I don't consider the latter VAXen to have 
   backplanes (that a big iron concept).

2) Nuke vsbus.  On the {MV,VS}2000/3100/4000, just connect the
   devices to mainbus0.  For example the VS4000/60 would be:

	mainbus0	at root
	le*		at mainbus?
	asc*		at mainbus?
	dz*		at mainbus?
	audioamd*	at mainbus?

   Internally, each processor would have a list of devices that
   are directly attached and their physical addresses and interrupts.
   A match routine would then resemble:

   int
   le_mainbus_match(parent, match, aux)
   {
	struct mainbus_attach_args *ma = aux;
	if (ma->ma_device_type == MAINBUS_LANCE)
	    return 1;
	return 0;
   }

    avoiding the use of ugly globals.

3) Add bus.h and intr.h.  To tie into #2 (and others), start moving
   the port to use bus_space and bus_dmamap/bus_dmamem.  I know this 
   has issues for the VAX port (and the slowness of CALLS/RET).  But
   this will mostly be an issue for the GENERIC kernel.  However
   this should cost next to nothing when generating a kernel for a
   specific platform.

3a) The VS4000s have 32,768 mapping registers so that the DMA done
    by the LANCE and the NCR53C94 can access all of memory.  This
    begs for the use of the MI drivers and the bus_* infrastructure.
    And the VS4000/{60,9x} can also have a TurboChannel slot but to
    use any device in it, see #3.

3b) The Unibus and Q-bus support should be moved to sys/dev/unibus
    (or qbus, but not uba).  This is so that eventually the pmax port
    can take advantage of it.  And it should use either a unibus_*
    API (which might mapped to a bus_*) or directly use bus_* API.


I know the above is a lot of work, but it really is required to 
fully support the latter VAXen models.
-- 
Matt Thomas               Internet:   matt@3am-software.com
3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt/
Sunnyvale, CA             Disclaimer: I avow all knowledge of this message