Subject: sys/scsi bug: adaptor-level driver miphys routine
To: None <tech-kern@NetBSD.ORG>
From: Jonathan Stone <email@example.com>
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
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*!)