cvs commit: src/sys/cam/scsi scsi_cd.c

[Poul-Henning Kamp]

In message <44570000.1065552539 at aslan.btc.adaptec.com>, "Justin T. Gibbs" write
s:

>No.  The trick is removing any retries so that retriable errors
>are ignored.  The "problem" never was the timeout value, but the
>drive returning "in the process of becoming ready" status that
>triggered error recovery to wait for the device.

No, the problem is that an inadequate programming model were
implemented where the distinction between "the drive mechanism"
and "the media" was not realized.

My patch doesn't implement that either, it is merely meant as
a stop-gap until such time where somebody will implement this
correctly.

It is only very reluctantly that I have ventured into this device
driver in the first place, but so far I have seen zero activity on
the part of the scsi soviet, despite this being on the table for
several years, and therefore I had to do something to be able to
move forward in other areas of the kernel.

I know full well that you have all been waylaid by the real world,
that's life, and I don't want to add to the stress you are under,
but after some reasonable timeout, the "thats not the way, please
wait for me to do it" has got to stop.

I've seen a lot of talk about CAM, locking of same, and even a CAMng
has been mumbled about, but I have yet to see any signs that we
actually have active maintenance of this area.

If you guys don't have time to update CAM and the peripheral drivers
to follow the rest of FreeBSD, in particular with respect to SMPng
and GEOM, then you should accept that, say so, and instead encourage
other people to move into the area.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.