On Tue, 6 Feb 2001, Chuck McManis wrote:

I'll try to be short. :-)

> DSSI also has hot swap capability. Do you want ra2 to vanish and re-appear 
> as ra6?

Why not? If that is what happens, then the devices should reflect that, I
believe.

> >The Q-bus on the other hand is a very generic bus. You can have a
> >controller on the Q-bus which actually looks like a massbus
> >controller. Where does that leave you? Are those disks hp(n) or
> >ra(n)? Plain incorrect view. An MSCP controller on the Q-bus will have
> >ra(n) disks, an RLV11 will have rl(n) disks, and if you would happen to
> >own a pure SCSI controller for Q-bus, you could have sd(n) disks on the
> >Q-bus.
> 
> Why? Not to be a pain in the ass (I know, too late!) but since MSCP can be 
> used as the protocol abstraction for all these disks why not use it? It 
> would sure make writing disk drivers a lot easier! Let's take the MSCPBUS 
> driver and hack it so that it uses as much of the hardware as possible and 
> then soft implements the rest. This is sort of what Direct3D tries to do 
> (sorry paradigm shift). Then you need only implement the "MSCP to RL" 
> mapping and the disk driver stuff would just fall out. Then *EVERY* disk in 
> the system could be an ra(n) disk!

You could of course write a software MSCP controller that uses the
underlying controller so that everything looks like MSCP, but it is silly,
and I assume that is your point. However, if you have hardware that
already are talking MSCP, it *is* a different story.

> My point is that some folks take a bicameral view here when it comes to 
> MSCP. It either *IS* the disk abstraction, or it isn't. If it is, then 
> build the kernel around it. If it isn't, then pick some other abstraction.

I agree.

> The only thing different is that I called the disk 'dd' rather than 'ra' 
> and unfortunately if you call it 'ra' then it wants to use major number 9 
> and that plops you into the mscp driver which won't have a clue.

You probably have a point here. I guess this is a problem with the current
ra driver. It should perhaps be split into two parts, so that you can
replace the controller-specific pieces...

> >For this discussion you should ignore the VMS device designations, since
> >VMS are a totally different ballpark. :-)
> 
> I find it interesting that one can argue both "follow DEC" with Ultrix and 
> "ignore DEC" with VMS. If it were up to me the device name would be 'di*' 
> and exactly match the name the prom shows. Sure would clear up some folks 
> confusion.

My point was rather that you argued that even DEC always made a
distinction, and I showed you that they didn't in Ultrix, which I think is
more relevant here than VMS...

> >This argument is bogus. Just like we aren't interested in the physical
> >characteristics for MSCP disks aren't we interested in the physical
> >characteristics for the ethernet. We are interested in the logical
> >protocol.
> 
> So why don't you argue for *ALL* disks to be based on an MSCP model?

Because I argue for all drivers to implement the interface that the
specific controller gives them.
I think it feels kindof silly if we all agree that the DSSI drives are
talking MSCP, and yet we have to implement another driver for them.

> Trust me the code to talk MSCP through the SII chip is very different than 
> the code to talk MSCP through the Qbus.

Oh, I have no doubt... I tried to find documentation for the CI interface
a few years ago, and while I didn't really succeed, I did find some
scraps...

	Johnny

Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt@update.uu.se           ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol