Subject: sys/scsi bug: adaptor-level driver miphys routine
To: None <tech-kern@NetBSD.ORG>
From: Jonathan Stone <>
List: tech-kern
Date: 09/18/1995 13:07:32
I'm re-writing a TurboChannel ASC (53c94, like the "esp")
driver using the machine-independent SCSI code in sys/scsi.

I want to use a minphys routine in the SCSI sc_link.adapter
switch to limit SCSI I/O requests to 8 Kbytes, since the
current driver doesn't deal with larger requests than that
directly, and fixing it is tricky.

It seems like the adpater->scsi_minphys function  does just
what I want.

*However*, adding debugging printf()s show it doesn't.
Adding a stack trace in sdstrategy() shows that sdstrategy()
is being called via clusterread().

Clusterread() is called in response to UFS read vnode requests;
but it passes the clustered reads via the following call chain:


I presume due to the  VOP_STRATEGY call in cluster_read().

Is this a bug?  Or a feature? If I'm missing something obvious, what is it?

If this *is* a feature, what on earth is the point of the
scsi_minphys() routines, and the drivers (e.g., in sys/dev/isa) that
use them?

I know I've heard certain individuals say that a strategy rotine in
the vnode layer is Wrong, and read and write operations are Right.
That's apparently what SunOS 4.1.x does.  I beleive the scsi_minphys
methods would Do The Right Thing on such a system.

I think butchering  spec_strategy() to call the underlying read or write
routines would solve my immediate problem, but I'm far from convinced
that it' the correct long-term solution.

I'd appreicate any help with this.  (Except advice to just fix the
adaptor driver to deal with blocks larger than 8k; I need to get the
bugs out of it *first*!)