Re: [Libcdio-devel] Fedora bug report concerning CD-TEXT

[Thomas Schmitt]

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