Re: CAM

[Pat Mackinlay <mackinla@cs.curtin.edu.au> writes:]

>Any idea what Plan9 or QNX do? Andy? I'm not sure, but I would have thought
>that a few context switches wasn't much compared to the speed of reading
>a reasonable amount of data from disk. Perhaps a good serve of blocking
>and buffering will reduce the impact?

My filesystem will definitely be able to do contiguous 64K reads, so you're
looking at amortizing 64K of I/O over one of these turnarounds. I think
it would be nice to group things into two sections: one for, say, Adaptec
1542b, and one for disk on top of it. From Michael's previous message,
this looks like PDRV and half of XPT in one process (up to the part
where the routing decision is made), and the rest of XPT plus the CAM
in the lower process.

I don't know how QNX breaks up their SCSI support; Plan9 is a traditional
monolithic kernel for purposes of I/O architecture.

Booting is really not a problem. You can load in the necessary CAM
and PDRV from the boot.lst. If you end up needing to boot elsewhere,
you just edit your boot.lst and pick a different CAM. I can see no
need for a "mother of all CAM" servers. I think I'm going to write a
message on the boot process for VSTa, so we can all talk about it without
requiring everybody to do a massive code read first.

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

CAM - Adaptor-specific management
XPT - "Transport" layer. Apparently routes between PDRV and a CAM
PDRV - Disk/tape/etc. code for creating SCSI commands

My hope is that XPT can be boiled down to choosing where to connect
from PDRV to CAM, and thus doesn't need to be a distinct process.
I don't understand its functionality well enough to comment on if
this would work... Mike?

                                                Andy
Received on Wed Sep 15 10:30:48 1993