From owner-freebsd-scsi Tue Oct 12 11:28:40 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 0911C157BE for ; Tue, 12 Oct 1999 11:28:19 -0700 (PDT) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id OAA05103; Tue, 12 Oct 1999 14:21:25 -0400 (EDT) Reply-To: Randell Jesup To: "Justin T. Gibbs" Cc: Gerard Roudier , scsi@FreeBSD.ORG Subject: Re: Driver for GDT6517RD RAID controller References: <199910121642.KAA34505@narnia.plutotech.com> From: Randell Jesup Date: 12 Oct 1999 14:23:43 +0000 In-Reply-To: "Justin T. Gibbs"'s message of "Tue, 12 Oct 1999 10:42:52 -0600 (MDT)" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Justin T. Gibbs" writes: >> You must distinguish between phase cognizant target mode and host target >> mode. What I intend to implement in the future is something that avoids >> stalling the phase engine as possible, thus host target mode. Note that if >I agree phase cognizant isn't that interesting. The aic7xxx driver works >in the fashion you describe. Phase cognizant is mostly useful for making -workalikes, and (primarily) for testing the initiator's SCSI implementation (by feeding it weird shit). I have no real interest in either at this point. >> As seen from SIM the handling of the target mode is in fact much simpler >> tham initiator mode, since the part that acts as a target has the baton in >> SCSI. So, a SIM that will only implement target mode should be >> significantly simpler than common ones that only implement initiator mode >> (given appropriate hardware). >Target mode isn't difficult, but I would refrain from calling it simpler >than the initiator role. There are several little gotchas mostly having >to do with resource deadlocks when running in both roles at the same time >and the initiator tells you that you cannot disconnect. Well, you could always punt and return an error in that case (though it's very not-nice to do so). I assume the problem becomes something like: command comes in with disconnect-disabled. You need to page (or otherwise access a disk) to fufill the request. The disk you need to access is on the same bus. Ooops. I forget if this was explicitly considered in the CAM subcommittee discussions, or if it was just felt that this was something that could not be dealt with. I wouldn't be surprised if we thought about it and agreed that it was not solvable, and that an error return was perfectly reasonable, and that in this sort of situation reselect-enabled was VERY strongly advised. I'm going to dig out my old mail archives from the Section 10 (now renumbered) subcommittee. (A lot happened over conference calls too; we never met in person.) Thanks for the info. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message