Hi, [off topic begin]
i wrote: > > avoid requesting more reply bytes than the drive might be willing to > > return. > > This might be necessary to avoid problems with operating system SCSI > > passthrough drivers. (There once were and there might still be in > > Linux.) Leon Merten Lohse wrote: > I really hope that this has become unnecesary in the year 2016. The general trend is rather towards regression. I want back my kernel 2.6. (But on 4x Xeon with 16 GB RAM, please.) In general the kernel code in sr.c and cdrom.c is not of better semantic quality as the code in libcdio or libburn. (I.e. needy of being worked on, at least.) You can even spot a riddled programmer making up an own urban legend about SCSI specs to explain the perceived fuzzy end of CDs. fgrep 75 drivers/scsi/sr.c This while not understanding the two run-out blocks of TAO and using a function from drivers/cdrom/cdrom.c which depending on drive age uses three different MMC fields from two different SCSI commands which can legally yield three different numbers. They managed to halfways cover the mess under a strange remedy which works only if the number of blocks of the CD is divisible by 2. (And i really don't know how it works at all.) blkid was daring enough to want to read the end of devices. Archlinux packed it into one of its ISOs. Those get stuck at Linux boot if they were burned onto CD with write type TAO. (Wheeze ... i need to calm down ... after all i can work around all three CD regressions in kernel 3.16 after only 9 months of ownership. Concurrent burn works well via /dev/sg, TAO end is not a problem to libburn, tray loading can be done by libburn so that it waits until the drive is ready for reading.) [off topic end] ---------------------------------------------------------------- Back to MCN and ISRC: If we decide to just augment the two existing functions mmc_get_mcn_private() mmc_get_track_isrc_private() without unifying their bodies, then we have a good excuse to dare the kernel to stand less reply than requested by caller. We have good chances that drives either refuse on the command or return at least 22 bytes. But this is not guaranteed by the specs. If we unite the two functions, then we should really do it as is appropriate for SCSI commands which at the beginning of their reply report the number of bytes to follow. First a short request to get the byte count. Then the request to get as many bytes as available. As a cream cap we'd get better info about the number of really valid reply bytes. Have a nice day :) Thomas
