CAM_NEW_TRAN- kernel changes ready for review

[Matthew Jacob]

On 10/28/06, Scott Long <scottl at samsco.org> wrote:
> Matthew Jacob wrote:
> > This has been updated after I found I'd forgotten to fill in a couple
> > of items (*cough*).
> >
>
> 1) I thought that you were just going to push forward and make NEW_TRAN
> be the de-facto.  Why bother keeping the #ifdefs?  If I misunderstood,
> I apologize.
>

I was going to push it in this way, which is the completion of
NEW_TRAN for drivers that didn't have it, have a few days of settle
time and then make the switch to remove the old code and make NEW_TRAN
the default.

> 2) Does the protocol_version field in the cts and cpi refer to the SCSI
> protocol (i.e. SCSI-1/2/3, etc)?  If so, isn't that more of a per-device
> quality, not a per-sim quality?  Hard-coding it in the SIM for all
> devices would then seem wrong, shouldn't CAM get it out of the INQ data?

Yes- this is a good point.

Note that this exercise I'm undertaking isn't to clean up NEW_TRAN
*as* we switch to it- it's to make the switch.

What really has to happen is some consensus has to be reached over
what NEW_TRAN actually means. As far as I know there is no design
document, and the original authors are only partially involved in this
exercise. Therefore, the actual meaning of what NEW_TRAN is  is
somewhat fluid- but I do believe we have had consensus for some time
that what it represents is the direction to go (thus the push to get
the ball rolling).
>
> 3) For atapi-cam, I think that the cts->protocol should still be
> PROTO_SCSI, not PROTO_ATA.  Having cpi->transport by XPORT_SPI also
> seems wrong, as IDE is fairly different from SPI, and I'd like at some
> point to have a real IDE/SATA transport that understands the
> differences.  For that matter, it might also be useful to differentiate
> between PROTO_SCSI and say PROTO_RBC or PROTO_ATAPI or PROTO_MMC.  Might
> make dealing with USB and firewire easier than the quirky mess that is
> there now.

Again- agreed.

>
> Otherwise, looks pretty good.  If you want to push forward and commit, I
> can help clean up any goofs or missed drivers.
>
> Scott

Thanks for the careful review.

Any opinions about the camlib/camcontrol issue?