Re: CAM

[myl@genrad.com (Michael A. Larson) writes:]

>I think that while the XPT should be a distinct process, it doesn't
>need to be in the path of most I/O transactions. The reason that the
>XPT should be a distinct process is that it owns several tables,
>including a table of SIM's currently running and a device table. Also,
>the XPT layer interfaces to both the PDRV's (eg, send a CCB to the
>appropriate SIM) and the SIM's (eg, tell the XPT I'm here).

Are you sure this functionality couldn't be subsumed by some conventions
in the use of the /namer name space?

>As for SCSI requests, each PDRV sends a CCB to the appropriate SIM via
>a function called xpt_action(). Now, xpt_action() could send the CCB to
>the XPT process, and let the XPT process send the CCB to the
>corresponding SIM. On the other hand, xpt_action() could contain a read
>only copy of the XPT processes tables and route the request directly,
>bypassing the XPT process. On the way back, the completion "callback"
>would normally bypass the XPT layer anyway.

But the selection of SIM is a static answer for a particular instance
of a PDRV, isn't it? So why couldn't have look it up once, via namer,
open a port to the right SIM server process, and thus make it unnecessary
to have a third process?

>Is this data copied, or, as Jonathon (jont@hsa.com.au) suggested
>previously, is the associated buffer shared among the servers in the
>I/O path?

Servers receive messages by having them mapped into the server address
space (more accurately, a view is attached, but the actual pages are
mapped on demand). If the server does not touch this data, but sends
a message on to another server, then the memory is never referenced
or mapped in the intermediate server.

My filesystem uses variable-length buffers for its buffer cache. The
buffer size is related to the size of the next extent in the file
being accessed. Thus, when vstafs send a read request, the page
view for the entire buffer would be passed through until it reaches the
server who actually stuffs the bytes into the buffer. His writes
go into the actual buffer memory of the filesystem; there are no
intermediate copies.

Programmed I/O, like the WD driver, behaves this way. True DMA devices
require the extra step that each page must be wired and its physical
address found. The floppy driver does this one page at a time; if you
have a device with scatter/gather DMA, you might wire multiple pages.

Gee, I'm feeling professorly today! :-)

                                                Andy
Received on Wed Sep 15 20:37:05 1993