Re: CAM

Andrew Valencia wrote:
>
> [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,
[ ... ]
Page faults are 4K ?
Making use of 64K reads will require a fine balance between VM management
and disk buffer management as well as some clever read-ahead.

> >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
SIM is the adaptor stuff, while CAM is the overall architecture.

> 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?
I hope that most of XPT and SIM can be joined as most systems will have more
PDRV than SIM. [ 1 HBA, and several types of SCSI devices. ]

JonT
PS Andrew thanks for the post on booting.
Received on Wed Sep 15 19:26:05 1993