Date: Sun, 29 Oct 2006 02:54:41 -0800 From: "Matthew Jacob" <lydianconcepts@gmail.com> To: "Scott Long" <scottl@samsco.org> Cc: freebsd-scsi@freebsd.org Subject: Re: CAM_NEW_TRAN- kernel changes ready for review Message-ID: <7579f7fb0610290254n21797c94y95413f2d271d9f2c@mail.gmail.com> In-Reply-To: <45443C7F.5040508@samsco.org> References: <7579f7fb0610281854l3ec600d7kf0a2cdf20fdcb838@mail.gmail.com> <7579f7fb0610282210p59de2123g379f0d4069bd1e42@mail.gmail.com> <45443C7F.5040508@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/28/06, Scott Long <scottl@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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7579f7fb0610290254n21797c94y95413f2d271d9f2c>