Re: Sense fetching [Was: cdrtools /devel ...]

Joerg Schilling wrote:
> Alexander Motin <mav_at_FreeBSD.org> wrote:
> 
>>> The question still remains whether the previous implementation did return resid 
>>>> 0 in some cases. In this case, I would need to implement both variants in the 
>>> libscg adaption layer and I would need to know whether I am running on an old 
>>> version or on a new version kernel. Do you know of a simple method to implement 
>>> this distinction?
>> Yes, some drivers were permanently reporting zero resid, while others
>> (mostly real SCSI) were reporting proper values. Now it is the same,
>> just more cases should work properly.
>>
>> Why do you want/need to distinguish them? You should already handle
>> non-zero resid properly. Zero resid may be wrong in some cases, but at
>> first I don't see fatal problem from it and at second I don't see what
>> can you do about it.
>>
>> If I am missing something - sorry, explain it to me please.
> 
> Compare the number of sense bytes I like to request (18) with the number 
> previous FreeBSD versions did actually request. It is obvious that in case 
> there is a resid reported onm an old kernel, libscg (with your chanhge) would 
> believe that probably less that the absolute minumum of sense data is available.

Kernel code I have changed affects only controllers without automatic
sense fetching. For such controllers CAM previously always reported zero
sense_resid, independently of requested size (which actually was also
ignored in this case). So previously whatever you asked for 18 or 32
bytes - sense_resid was always zero, like if you got full 18 or 32
bytes. That was wrong. Now, in the same situation, if device wants to
return let's say 20 bytes -- you will get 0 and 12 bytes of sense_resid
respectively, meaning 18 and 20 bytes of received sense.

AFAIK sense_resid always measured from the requested sense_len. In my
patch for libscg you may see that I have changed both request and
response paths. Resulted sense_count should be absolutely the same.

-- 
Alexander Motin