Re: Querry !

[Stephen Bailey <steph@cs.uchicago.edu>]

Kaushik,

I'm not quite sure what your proposing here, but something seems
wrong.  Just fyi, I have worked on several CAM-based initiators (who
was it that was saying CAM was never implemented?).

You have mentioned `iSCSI target stack' several times.  Are you trying
to make FreeBSD behave like a storage target?  If so, you should
probably not be using CAM at all.  CAM is about implementing
initiators.  It does define a target mode path, but it is relatively
limited in scope.  CAM target mode is good for implementing a SCSI
processor target (for things like cluster communication and bus
pinging), but I don't think it was intended for a richer target
(e.g. a storage target).  It's defined for connectivity, but not
performance in the target role.

If you are trying to make a FreeBSD iSCSI initiator, then what your
saying here:

> won't it be feasible if we can write a pseudo driver that takes care
> of the fetching the scsi cdb as such and passing it on to the SIM
> driver ? In a way we will get away from the PM functionality which
> forms the scsi CDB in case of a normal I/O.

doesn't make sense to me.  You don't want to `get away' from the
periperal drivers, since the are your ultimate clients.  The whole
design of CAM is to allow peripheral drivers (disk, tape, etc, for the
unCAM-oriented) and SIMs (SCSI Interface Modules, aka adapter drivers)
to be independent so that the same PDs work no matter what SIM.

To make a FreeBSDI iSCSI initiator, you need to write an iSCSI SIM.
To do that, you probably shouldn't start with an iSCSI target stack.

One trick doing this with CAM is that it didn't really anticipate the
different addressing characteristics of the various SCSI transports (a
problem not unique to CAM).  CAM was designed anticipating lots of
different ||SCSI adapters, rather than adapters with completely
different transports.  The standard solution to this (done in FCP, for
example), is to store some transport-specific translation state in
your SIM to map, say, target xx to a particular transport address (an
FC WWN, or iSCSI socket address).

Another trick will be getting to the network stack from the SCSI
stack, and vice versa.  Not impossible, but you may have to be careful
calling the network stack from the storage stack, as they're typically
in different synchronization domains.  Sometimes trying to get
synchronized on both domains simultaneously can lead to surprising
deadlocks.

Steph