On Tue, 6 Feb 2001, Chuck McManis wrote:

> 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.

That depends! If you say ra*, then it's so, but you can just as well say

ra0 at mscpbus0 drive0

and then it won't move around, I promise. :-)

> > > 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 :-)

This is an interesting argument. :-)
But that soft MSCP layer will not give you anything sensible. You have not
made anything easier. The driver that you previously had to implement,
that gives you the abstract Unix look at devices have now been replaced
with the abstrace MSCP look at devices, which is just as much work to
implement (more actually), so it's just as well to go directly at the end
result. I know that this is what you are arguing for the DSSI driver, but
what others are saying is that the most direct path between a DSSI drive
and the kernel might as well go through the mscpbus stuff. If done
correctly, it won't be any more work for the CPU, and yet it means you
don't get two different MSCP drivers.

The scsibus thing pointed out previously is a nice comparision. scsibus
can exist on top of USB, which is a very interesting parallell.

	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