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:
> 
> ftp://ftp.t10.org/t10/drafts/spc2/spc2r18.pdf
> 
> 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 <bouyer@antioche.eu.org>
--