Subject: Re: SCSI drivers & devices resources
To: Matthew Jacob <email@example.com>
From: Manuel Bouyer <firstname.lastname@example.org>
Date: 10/22/2000 13:26:46
On Sat, Oct 21, 2000 at 08:54:52PM -0700, Matthew Jacob wrote:
> > Hi,
> > On Fri, Oct 13, 2000 at 10:22:52AM -0700, Matthew Jacob wrote:
> > > [About REPORT LUNS]
> > > It's a SCSI-3 command, but like a lot of commands that come in with a new
> > > version of the spec, devices claiming compliance with a lower level just
> > > support it.
> > Could you send me the specs of this commands (opcode, result format, etc) ?
> Hmm? Didn't I send a working example already? I could have sworn I had....
I missed it then ...
> The specs can be found in SCSI Primary Commands... you can find this
> in http://www.t10.org..., or the full link for the current one is:
> I can take a swack at implementing this for NetBSD next week sometime.
Hum, maybe I'm going to wait a bit :)
> > For my needs I added a SC_ACCEL_NODEV flag to SCBUSACCEL, and an IOCTL is
> > done when a probe failed as well.
> Is this checked in yet?
No, not yet. I just did this so that I can keep working on tagged queuing
for siop. Now that I have it working I'd like to commit it ;)
I just need something that get called after a target/lun probe which
tells if there is a device here or not, so that I can alloc resources to
handle it more efficiently, or free the minimal resources allocated to
do the probe.
> > BTW, why do you call SCBUSACCEL only in the checkdtype case ?
> > I think it should also be called for a vendor-specific device-type qual.
> No, I wouldn't think so- a vendor-specific qualifier .. .well, now... have you
> actually ever seen one that wasn't actually a bug in an HBA that returned 0xff
> for all the INQUIRY data?
No, I agree. But it's supposed to be possible, isn't it ?
> I suppose we could skip this test and just put the ioctl call after the
> checkdtype test case.
This is what I did actually.
Manuel Bouyer <email@example.com>