target driver question

[Justin T. Gibbs]

> This is a fibre channel target driver. So the data consists of login
> information about the initiator on the other side of the link, an
> exchange ID (OX_ID), and a couple of chip resources specific to this
> IO.

Okay.

>> The two other drivers that perform target mode in FreeBSD do not require
>> any data other than the init_id and tag_id to be "round-tripped" through
> 
> Does the combo of init_id and tag_id uniquely identify an IO? If so, I
> guess the driver could keep track of the IO specific data in a "table"
> indexed by init_id/tag_id.

In the future, the CCB data structures will contain transport specific
sections so that native transport addressing can be used.  Until then,
the init_id/tag_id are all that we have.  Considering that the ATIO
already has this information, and the ATIO lifetime should encompass
all CTIOs generated in response to that ATIO, these two fields could
easily be replaced by a link to the "parent" ATIO.

>> the target emulator.  I would rather not have the target emulator touch *any*
>> of the private data or to see a SIM driver rely on anything other than the
>> standard fields in the CTIO.  If this is absolutely necessary, we can
>> add a way to refer to the ATIO from the CTIO since the ATIO lifetime
>> is the lifetime of the SCSI transaction being serviced.
> 
> I think I can live with this. The above is a little bit more work, but
> not a big deal. Other layered driver code that I've worked on before
> either had a concept of handles or provided a hook for private (device
> dependent) data. When I saw the sim_priv structure, that is what I
> expected it to be.

The private areas are convenient storage during the lifetime of a CCB.
Your problem is that there is no relationship between the ATIO and
CTIO.  I don't think that there would be any problem in rectifyin that
problem.

--
Justin