At 12:03 PM 2/27/2002 +0100, Johnny Billquist wrote:
>On Wed, 27 Feb 2002, Jochen Kunz wrote:
> > On 2002.02.27 05:04 Gunther Schadow wrote:
> >
> > > I would assume that peeking into the Ultrix 4.2
> > > source code could be of great help.
> > This may lead to serious copyright problems, even with a "cleanroom
> > reverse engineering approach". I think BSD has suffered enough from such
> > problems. Additionaly Ultrix may be that different, that it may be
> > easier to write somthing new from scratch, than port ancient Ultrix code
> > to NetBSD.
>
>True about the copyright problems.
>However, the Ultrix driver is a beautiful beast. When you declare an MSCP
>disk, you don't say where it's located. You just say:
>disk ra<x> at mscp drive <y>
>
>Controllers are declared as:
>controller uda0 at uba0
>controller uq0 at uda0
>controller hsc0 at ci0
>
>And then the disks can be either at hsc0 or uq0, and you can move them
>without problems.
>DSSI is yet another, and so on...
>
>This nice solution comes from the fact that Ultrix divided the driver into
>two parts (as does all DEC OSes), the class driver and the port
>driver. The class driver handles all mscp disks, no matter how they are
>connected to the system. The port driver handles the passing of the
>physical messages between the controller and the system. Port drivers are
>individual for each type of hardware. Port drivers can also be used by
>other stuff than MSCP, such as DUP, TMSCP, or IP for that matter.

Note that SCSI is split in approx. the same way in both VMS and NetBSD.
You have a port (board) driver and the class (common) driver.

Now a GENERIC kernel might have:

device sii* at ibus?
device shac* at ibus?
device uda* at qbus?
device klesi* at qbus?
device klesi* at bi? node ?
device kdb* at bi? node ?

device sii* at ibus?
device shac* at ibus?
device ci* at sbi?
device ci* at bi?
device ci* at tc?

device hsc* ay ci? node ?

device ld* at mscpbus?
device lt* at mscpbus?

Now both uqssp and hsc would have an attribute of mscp which says the
device is the root of an mscpbus.  Now I think that mscp should not use
ra disks, but the generic ld disks used for raid and i2o controllers
since adding a level of abstraction to the disk is exactly what MSCP
does.  However, a lt (logical tape) driver would need to be written.

device autoconfiguration needs to have string locators since hsc really
wants a node string attribute.

> > > However, I thought that NetBSD already supports RA disks, so,
> > > the MSCP protocol should be there.
> > Yes. NetBSD has already MSCP drivers. But guessing a bus protocol on
> > bais of a device driver is somewhat painful. Also guessing is no good
> > bais for new code.
>
>True. And also, the NetBSD RA support have some bug in it, along with
>being very much tied to the UDA50/KDA50 right now.

In an ideal world, we'd have a common UQSSP driver with different bus
attachments (uqssp.c uqssp_qbus.c uqssp_bi.c) to handle local controllers
and a defined interface such that a DSSI or CI port driver could have
MSCP over SCS attach to it.

Actually, I said most of the above 5.5 years ago:

http://mail-index.netbsd.org/port-vax/1996/11/27/0004.html


-- 
Matt Thomas               Internet:   matt@3am-software.com
3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt/
Cupertino, CA             Disclaimer: I avow all knowledge of this message