Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 28 Oct 2006 23:30:39 -0600
From:      Scott Long <scottl@samsco.org>
To:        Matthew Jacob <lydianconcepts@gmail.com>
Cc:        freebsd-scsi@freebsd.org
Subject:   Re: CAM_NEW_TRAN- kernel changes ready for review
Message-ID:  <45443C7F.5040508@samsco.org>
In-Reply-To: <7579f7fb0610282210p59de2123g379f0d4069bd1e42@mail.gmail.com>
References:  <7579f7fb0610281854l3ec600d7kf0a2cdf20fdcb838@mail.gmail.com> <7579f7fb0610282210p59de2123g379f0d4069bd1e42@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

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?

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.

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

Scott





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45443C7F.5040508>