From owner-freebsd-scsi Tue Oct 12 13:33:45 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front1m.grolier.fr (front1m.grolier.fr [195.36.216.51]) by hub.freebsd.org (Postfix) with ESMTP id 90C4314C0A for ; Tue, 12 Oct 1999 13:33:41 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-116-142.villette.club-internet.fr [194.158.116.142]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id WAA20849; Tue, 12 Oct 1999 22:33:28 +0200 (MET DST) Date: Tue, 12 Oct 1999 22:55:19 +0200 (MET DST) From: Gerard Roudier X-Sender: groudier@localhost To: "Justin T. Gibbs" Cc: "Justin T. Gibbs" , scsi@FreeBSD.org Subject: Re: Driver for GDT6517RD RAID controller In-Reply-To: <199910122003.OAA02480@caspian.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Justin, I cannot follow the entire discussion, since my english is not so fluently and I donnot have much time for that. I thanks you very much for the explanations, even if I am not actually convinced by all your arguments. Will just reply on a few points.=20 =20 On Tue, 12 Oct 1999, Justin T. Gibbs wrote: [ ... ] > >There are errata everywhere and one who wants to provide reliable PCI > >device driver for portable O/S must be aware on the erratas of the PCI > >device and at least of the functionnal description of existing host > >bridges when available (erratas will be a plus but aren't always > >available). The way the CPU handles write buffers must also be considere= d, > >especially when using MMIOs. Even a feature can become a bug, given all > >that mess. >=20 > So each driver author must reinvent the wheel here? That seems silly. > Provided the OS provides a rich set of primitives and the author understa= nds > when those primitives must be used, the end result is the same without > duplicated code and complexity. When a new chipset with new bugs comes > out, I don't want to touch all of the 100's of drivers in the system agai= n. > I want to update one piece of code and have the rest benefit. If the goal is to fix device bugs by generically castrating features and performances when bugs are suspected, then we just aren't on the same planet, and I agree that this can help a little.=20 Communism didn't work for politics, may-be it works for software. Who knows?. ;-) I just hope this will not lead to use truck wheels for bicycles or vice-versa. ;-) [ ... ] > >AFAIR, in CAM3, the target peripheral driver can require disconnections = to > >be used. In this situation the initiator must just be refused to be serv= ed > >when it disallows disconnections. And if both target and initiator parts > >actually want to waste SCSI bandwitch, we just have to 'dont_care' and > >behave as both parts did agree. >=20 > In general practice you can't make this restriction. Often you are not > in control of the code on the initiator. Many drivers/controllers will > perform REQUEST SENSE operations without the disconnection privilege and > you can't simply bail every time a REQUEST SENSE is performed. The disconnect priviledge applies in a per command manner. On a really usable system, REQUEST SENSE should not happen very frequently. So, it is just a no-issue. My concern was about the common case of data transfers not allowing disconnections for the corresponding transactions. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message