> >   Note that my point isn't about RLV controllers in particular...I'm
> > talking about *all* the older hardware.
> > 
> >   Again, I think it should be a low priority, but I feel it would be
> > of value.
> > 
> Actually, if someone writes a device driver for RLV11, or whatever, I
> see no reason _not_ to include it in NetBSD.

Isn't it harder than just writing the RLV11 device driver?  After
all, you have to make sure that *nothing* else in the OS attempts
to address any of the 15 "extra" copies of the RLV11 device registers
that regularly occur every 256kbytes.  Doesn't this require a
careful survey of everything else in the OS, and very likely rewriting
some hairy things like I/O map allocations?  It'll probably also
involve many unexplained crashes when other parts of the OS hit
the extra copies of the RLV11 device register and prod it into doing
something it shouldn't, and many many hours of debugging to fix each
occurence of such a catastrophic failure.

This will probably make Q-bus graphics support especially difficult, as you
have to be sure that none of your graphics buffers are over 256k long
and that they are all aligned properly.

Support for less-brain-damaged 18-bit DMA devices is much more
straightforward - for example, for a RXV21 all you need is a "bounce-buffer"
in the lower 256 k for DMA's to go to/from.  This is much simpler than
RLV11 support.

IMHO, the effort should be placed on fixing drivers that used to work
in NetBSD until an "upgrade", such as the TSV05/TU80/TS11 class driver
that was broken several years ago (for reasons that I don't understand,
and I don't know how to get access to the several-year-old sources to
figure out exactly what was broken.)

Tim. (shoppa@triumf.ca)