Joerg Schilling wrote: > Alexander Motin <m...@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 _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"