Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Oct 1999 22:55:19 +0200 (MET DST)
From:      Gerard Roudier <groudier@club-internet.fr>
To:        "Justin T. Gibbs" <gibbs@caspian.plutotech.com>
Cc:        "Justin T. Gibbs" <gibbs@plutotech.com>, scsi@FreeBSD.org
Subject:   Re: Driver for GDT6517RD RAID controller 
Message-ID:  <Pine.LNX.3.95.991012223046.837A-100000@localhost>
In-Reply-To: <199910122003.OAA02480@caspian.plutotech.com>

next in thread | previous in thread | raw e-mail | index | archive | help

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.95.991012223046.837A-100000>