At 01:31 AM 2/7/01 -0500, Lord Isildur wrote:
> > DSSI also has hot swap capability. Do you want ra2 to vanish and re-appear
> > as ra6?
>
>yes, if it's now on id 6.

Currently the disk subsystem doesn't work that way. MSCP disks are numbered 
sequentially from 0 in the order in which they are probed. So for example 
on the CQD220 controller disk target 0 and disk target 3 become ra0 and 
ra1, then disk 1 on the second controller becomes ra2, etc. If you remove a 
drive and re-add it then it would change its disk number which has no 
relation to its 'id.'

> > So why don't you argue for *ALL* disks to be based on an MSCP model?
>
>  because not all disks talk MSCP
>massbus disks don't, SCSI disks dont, etc.

And my question is, this is simply a matter of software abstraction. It 
would be fairly trivial to write the "other side" of the MSCP protocol (ie 
the target side)  and have it do the talking to the other interfaces. This 
is exactly what a Qbus SCSI controller does today, the processor on the 
controller is talking MSCP but the disk is talking SCSI. Why not make the 
VAX the processor in question? It would make supporting new disks a whole 
lot easier than it is today since you need only write the "glue layer" that 
exports MSCP on one side and the basic disk functions on the other, further 
MSCP is all simple read/write with logical block numbers so no strategy 
routine necessary to get up and running, no disk device at all. Just a 
config linkage and a call in the disk device controller driver that 
"accepts" the MSCP packets. (I'll give you a hint, this is what my DSSI 
driver is doing :-)

>... should be rewritten to be a
>generic mscp driver, and then directed to talk over various different
>drivers to get to devices.

And *if* you do this, then you have done exactly what the if_net layer does 
in the kernel, presents an "ideal" network interface that can then have 
lots of different "physical" back ends but talk to the exact same IP stack. 
So you make MSCP the "disk access stack" and (not unlike some ethernet 
chips), you use exactly one high level disk stack, and you write a bunch of 
"simple" driver thingies that take MSCP on one side and drive the actual 
disk on the other. In the simplest case one would simply "pass through" the 
MSCP packet to the disk controller, in the home grown IDE interface case 
you would have to write a module that implements the basic MSCP protocol.

Further, you could do things like "ND" the old network disk protocol over 
ethernet and get big disks for 'free.' on your VAX.

IMPORTANT NOTE: To everyone on the list, this sort of discussion is useful 
and informative. And while I certainly disagree with some of the views 
presented the worst that could happen is that we get a working SII 
interface that Matt can plug MSCP into one day and downloadable kernels 
that support DSSI today. None of the work that I am doing is constrained in 
any way in terms of use, modification, and/or redistribution it will all be 
public domain. (this is even better than GPL btw :-)

--Chuck