From owner-freebsd-scsi@FreeBSD.ORG Sun Oct 29 10:54:43 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE52716A40F for ; Sun, 29 Oct 2006 10:54:43 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 372DB43D58 for ; Sun, 29 Oct 2006 10:54:43 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: by nf-out-0910.google.com with SMTP id p77so1873222nfc for ; Sun, 29 Oct 2006 02:54:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hjJnVhRV9NGafrpHTjkbK79Lq6xCd7DSOd6+7E7RqYhXh8/PxVMLa3TDDOSzwl5COPV36htsOFGS+34ola4V6EKrI8tftBWldwKqqaKiWN+i73pmj4RBNu6IXmEBxScw3RpFjTvSh5oAnEEsAGYELNlkTdWS1mYoYAV0mno/0cE= Received: by 10.78.127.6 with SMTP id z6mr2819425huc; Sun, 29 Oct 2006 02:54:41 -0800 (PST) Received: by 10.78.199.15 with HTTP; Sun, 29 Oct 2006 02:54:41 -0800 (PST) Message-ID: <7579f7fb0610290254n21797c94y95413f2d271d9f2c@mail.gmail.com> Date: Sun, 29 Oct 2006 02:54:41 -0800 From: "Matthew Jacob" To: "Scott Long" In-Reply-To: <45443C7F.5040508@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7579f7fb0610281854l3ec600d7kf0a2cdf20fdcb838@mail.gmail.com> <7579f7fb0610282210p59de2123g379f0d4069bd1e42@mail.gmail.com> <45443C7F.5040508@samsco.org> Cc: freebsd-scsi@freebsd.org Subject: Re: CAM_NEW_TRAN- kernel changes ready for review X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2006 10:54:44 -0000 On 10/28/06, Scott Long 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?