From owner-freebsd-scsi Mon Jan 29 14:56:00 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA18088 for freebsd-scsi-outgoing; Mon, 29 Jan 1996 14:56:00 -0800 (PST) Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA18079 for ; Mon, 29 Jan 1996 14:55:51 -0800 (PST) Received: by Sysiphos id AA04501 (5.67b/IDA-1.5 for freebsd-scsi@FreeBSD.ORG); Mon, 29 Jan 1996 23:55:42 +0100 Message-Id: <199601292255.AA04501@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Mon, 29 Jan 1996 23:55:42 +0100 In-Reply-To: Julian Elischer "Re: scsi cleanup" (Jan 28, 14:02) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Julian Elischer Subject: Re: scsi cleanup Cc: freebsd-scsi@freebsd.org Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk On Jan 28, 14:02, Julian Elischer wrote: } Subject: Re: scsi cleanup } > Get the SCSI target interface working on something other than just } > the AHA-1542B working - specifically on the two drivers we have control } > of the firmware (NCR and ahc). Add interfaces to support TCP-IP over } > SCSI. } now we're getting more long-term :) Yes, I'd be interested in implementing this for the NCR. } > Reduce the size of the NCR driver so that it is less than 7000 lines. Definitely true, and I've already been working on that, too. But note the amount of comments in the file, it could easily be reduced to half the number of lines by stripping off all the comments :) I've already completely designed a new "SCRIPT" language and will implement it as soon as possible. It is a much compressed form of the NCR code to be executed (a copy is required anyway for execution) and will allow to add support for the advanced features of the 53c810A, 53c860 and 53c875 (the last one offers an on-chip SRAM, which can be used for microcode and variable storage). It will require some testing (I won't release it before it hasn't successfully run for at least a week and one make world per night :) } Add: } Justin would like a call-down from the generic code to the adapter at the time of allocating a scsi_transfer struct, so that he can also allocate a matching } adaptrer level struct and pin them together.... The NCR driver could take advantage of a per controller (instead of per device) limit of outstanding commands. I'd also like to see more support for CHECK CONDITION/REQUEST SENSE by the generic code: The NCR work queue is a circular buffer and it takes extra code to start the failed command another time, after a CHECK CONDITION situation. If the generic code re-issued the complete command, the start queue management could be simplified. (I know there are some callback hooks in the generic code, but on first glance it wasn't obvious whether it is already possible with the current code). Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/~se