Re: CAM

Jonathon Tidswell <jont@hsa.com.au> writes:
> Im a little apprehensive about having 4 processes between a disk read and the
> disk:
> client ==> disk-FS ==> PDRV ==> XPT ==> SIM ==> disk
> [ and back - though this MAY be shorter ]
> Noting that each one is a context switch even if the data is 'copied'
> using VM mappings, the registers and VM mapping must be saved and flushed etc

and

Pat Mackinlay <mackinla@cs.curtin.edu.au> writes:
> One other thought - could you go over the various components and what they're
> supposed to do again? Can any of them be combined into a single driver
> without losing configurability?

Well, Jonathon and Pat have hit on a key issue for implementing any
SCSI driver: efficiency vs configurability.

The SCSI (CAM) driver could be implemented by putting all modules
(PDRV, XPT, and SIM) into a single monolithic process. (Most SCSI
drivers that I know of are implemented this way - all modules share a
single address space). These drivers are typically statically linked.
So, for example, adding a new SIM module might require adding some
entries to a table, a compile, a link, and a re-boot. In addition, you
need a "generic" kernel or SCSI server that contains all SIM's so the
operating system could be initially booted on any system that has one
of the supported SCSI HBA's.

Alternatively, the SIM's (with possibly some XPT functionality
included), could run as separate server processes. In this scenario,
the boot program would be told to run the PDRV's and the appropriate
SIM(s). For the average user, this is much nicer to manage, IMHO, than
the monolithic scenario above.

Now, is there a middle-of-the-road approach? I suppose that SIM's could
be dynamically loaded by a monolithic SCSI (CAM) driver. But there's
a chicken-and-egg bootstrap problem here, and I don't really know
enough about vsta to tell if this is feasible.

                                        Mike Larson
Received on Wed Sep 15 08:04:25 1993