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

Joerg Schilling wrote:
> Alexander Motin <mav_at_FreeBSD.org> wrote:
>>> Your patch to libscg looks definitely OK if we only look at the new corrected
>>> kernel driver behavior.
>>>
>>> There is a problem:
>>>
>>> In case that there is a sense data residual > 0, libscg will asume that there 
>>> is less sense data that really present in case that a "new" libscg is runnung 
>>> on an old kernel.
>>>
>>> Given the fact that many drives will probably only return 18 bytes of sense 
>>> data, this will happen every time libscg is told to fetch more sense than the 
>>> drive is willing to return.
>>>
>>> Is there a way to distinct an old kernel from a new one?
>> I don't see the problem. Previous kernel in most cases reported
>> sesnse_resid == 0, lying that there is more sense data then really is.
>> New one should report real (often positive) value. In both cases
>> sesnse_resid value measured from the value submitted to the kernel.
> 
> Did the old kernel return  a zero sense_resid for any implemented SCSI 
> transport? Libscg is a generic SCSI transport library and cdrecord is just one 
> user of this lib.

Not sure I understand your question. Zero sesnse_resid is absolutely
normal situation if device gave same amount of sense as application
requested. As I can see, many of SCSI controllers report sesnse_resid
properly. I may assume that some, like atapicd don't -- in that case
you'll also see 0 there.

>>> I see no advantage in removing the call to fillbytes().
>> scgcheck tests how much sense data received by counting 0x00 and 0xff
>> bytes. Zero-filling response buffer breaks that check. Though I have no
>> idea if other crdtools' applications depend on these zeros. There could
>> be some internal inconsistency.
> 
> O, I need to check other low level transport adaptation layers and think about 
> this statement.
> 
>>> Did you test a modified libscg on an unmodified kernel?
>> Unmodified kernel by default doesn't return any sense data at all for
>> new CAM-based ATA -- this changes should be invariant. New scgcheck runs
>> same bad as old. It just can't become worse. :)
>>
>> Legacy atapicam wrapper ignores sense_len on input and doesn't fill
>> sense_resig on output -- I haven't tested, but it also should be invariant.
> 
> I am not only talking about ATAPI but abut SCSI in general.
> 
> Do you know the CAM behavior for other SCSI transports?

I don't have real SCSI CD to test, but a as I can see, most of SCSI
controllers return sense data automatically. Sense fetching changes
should not affect/break anything there.

-- 
Alexander Motin