At 01:29 PM 2/6/2001 -0800, Matt Thomas wrote:
 > Seriously though, NetBSD tries very hard to do things right rather than
 > quickly.  I think it would be best to do the right way.  Especially if you
 > ever want to see it committed. :)

Ok, a bit more serious response in two threads:

#1) The Little Red Hen : That would be me. No one on this list or 
associated with the NetBSD/VAX project has had both the time and 
inclination to write support for the on-board DSSI controller. So, using 
the power vested in my by the term "open source." if I'm doing it on my own 
nickel, I'll do it the "right" way, as I see the "right" way to do it. Fair 
enough?

#2 What is "right" ? The argument Matt proposes goes something like this:
	"The DSSI bus is actually just speaking the MSCP protocol so this
	 is just another MSCP drive, make the mscpbus attach to them."

    This is the "protocol centric" argument. If you applied it to 
everything then you would have to also argue that SCSI controllers that 
appear on the Q-Bus should have their disks labelled sd(n) since they are 
talking the SCSI protocol. Except of course you can't do that, because you 
can't really know what protocol is being used to talk to the disk, you can 
only know what *interface* is being used.

     Now to my way of thinking BSD has always been *interface* specific, 
which is to say disks that are connected through the MASSBUS interface are 
hp(n), disks that are connected through the Qbus interface are ra(n), disks 
that connect through the SCSI interface are sd(n), and disks that connect 
through the DSSI interface are dd(n). Yes, even DEC does this with their 
hardware, do the DSSI disks connected to the DSSI interface show up as 
'DU*' ? No, they don't. They are 'DI*'. SCSI bus on a local interface? DK*. 
But SCSI bus on the Qbus? DU* again. If the same damn disk is connected to 
the KFQSA and talked to with the same protocols, it becomes a 'DU*' disk 
because the KFQSA is on the Qbus.

    Now if you want to choose which argument is "right" then you might 
measure correctness by how many exceptions there are to the application of 
the argument.

Q) Are SCSI disks on Qbus controllers treated differently than SCSI disks 
on SCSI interfaces?
	Mr. Protocol Answer: Um, yes, even though they have the same protocol
		when they are attached to the qbus we treat them as something else.
	Mr. Interface Answer: Yes, because they are attached by different
		interfaces they are identified differently.

Q) Are DSSI disks on Qbus controllers treated differently then DSSI disks 
on DSSI interfaces?
	Mr. Protocol Answer: Nope, since the kernel talks MSCP to both of them we call
		them ra devices always.
	Mr. Interface Answer: Yes, because they are attached by different
		interfaces they are identified differently.

Notice how Mr. Interface can re=use his same consistent answer but Mr. 
Protocol has to explain things a bit more. My sense of 'right' is the 
principle of least surprise, hook a disk up to a different interface and 
you are least surprised if it has a different type, reflecting that interface.

Pretty much everything in the DEC universe considers DSSI disks connected 
to DSSI interfaces to be "different" from disks connected via the Q-bus, I 
don't think it would be right to start confusing people now.

To add a final nail in what I consider to be the Mr. Protocol argument, ask 
yourself this question, how come every network interface that produces 
ethernet signalling levels isn't called 'eth'? Why le0, ze0, qe0, etc? My 
belief is that the Right way to differentiate devices is by their 
interface, and these are different interfaces to the same media, the 
network. I'm building a bridge using a new interface to an existing media, 
disks. I'm giving it its own name.

That being said, and if you're still reading you enjoy good theatre :-), I 
certainly intend to re-use code in the kernel that implements the MSCP 
protocol, that being the essence of good system design. But I won't write 
this driver to confuse people into thinking the disks are connected via the 
Qbus. If that means it will never be part of the 'official' release, I can 
live with that.

--Chuck