> 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. 
> 
> If I read the SHAC docs correctly CI is just another protocol, the chip 
> lets you set up mailboxes and can interrupt you when things get posted 
> there. Kind of like a bit of shared memory amongst cluster members.

the SHAC has a microcoded firmware, which it gets by having one of its 
registers poked with the base address in physical space of the code, usually
thi sis done by the boot code. in ultrix/vms, this is done by VMB before 
the system boots. 

> 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 

exactly. all the MSCP-talking devices should be treated with the same 
driver. 
That driver might need to talk to different drivers underneath, for example
a Qbus interface, or a CI bus interface, or a BI bus interface, but it's
still MSCP

> mapping and the disk driver stuff would just fall out. Then *EVERY* disk in 
> the system could be an ra(n) disk!
only MSCP disk controllers. remember, its not the disk thats MSCP, but 
the controller. 
the RQDX3 is an mscp controller. A DSSI disk's logic contains an HSC, 
which is an MSCP controller. A CMD CQD220 is an MSCP controller. 

>          1) Device naming - what does a device name "mean" (if anything)?

it refers to what driver is the interface to it. 

>    Why aren't all ttys tty0 - tty999 ?
>    Why aren't all disks disk0 - disk999 ?
>    Why aren't all network interfaces ether0 - ether999 ?
>    Why aren't all framebuffer fb0 - fb999 ?
>    Why aren't all tape devices mt0 - mt999?

 because theyre not the same drivers. 

> Does the user care? Should the user care? At Sun we decided, "Nope, the 
> user shouldn't care" and notice how all the disk devices in Solaris are 
> /dev/dsk/c0t0s0 (that is "controller 0", "target 0", "slice 0") nobody 
> cares if the disk is fiber channel, scsi, smd, etc. Its a disk. And it has 
> a /dev/rdsk flavor as well.

oi! i _hate_ those naming schemes!! hahahaha
(just my own preference there) 
> 
> 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. 

> Trust me the code to talk MSCP through the SII chip is very different than 
> the code to talk MSCP through the Qbus. But again, if you feel strongly 
> about this why not argue it like the ifnet layer on network devices? Create 
> the virtual disk (like the virtual network interface) and simplify one's life.

but, this is because our MSCP driver comes from the bsd uda driver which is
specific to the uda50 and its clones, and should be rewritten to be a 
generic mscp driver, and then directed to talk over various different 
drivers to get to devices. 

> >Whichever way you decide to implement this, I hope you get it running,
> >many will thank you.
> 
> That will of course be the fun part :-)
> --Chuck

indeed! 

happy hacking!
isildur