Re: trixie: cdrecord can no longer write to CD

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

Max Nikulin wrote:
> return 0 != uname(&buf)
>   || 2 != sscanf(buf.release, "%d.%d", &major, &minor)
>   || major > 2
>   || (major == 2 && minor >= 6)

Urm, wouldn't this change the return value in the first two cases ?
If uname() says -1, then the old function would return 0 and the new
one would return 1.
(0 is the better blind guess. See below.)

If i should write it from scratch, then i would invest in clarity:

   if(uname(&buf) != 0)
     return 0;
   if(sscanf(buf.release, "%d.%d", &major, &minor) != 2)
     return 0;
   if(major > 2)
     return 1;
   if(major < 2)
     return 0;
   if(minor >= 6)
     return 1;
   return 0;


> However since it was for renaming to scd<N>, I am not sure that conditions
> should not be modified for sr<N>. This uncertainty at least deserves a
> comment.

Up to kernel 2.6, it was necessary to put IDE/ATAPI CD burners under
control of the ide-scsi kernel module, so that /dev/hdX was accompanied
by a /dev/sgN which was willing to accept ioctl(SG_IO) or its
predecessors.
  https://litux.nl/mirror/linuxcookbook/0596006403/linuxckbk-CHP-11-SECT-3.html

On the way to Linux 2.6 the ability to perform ioctl(SG_IO) was given
to the block level devices /dev/hdX, /dev/srN, /dev/scdN, so that the
ide-scsi module became obsolete. That "new" state is described in
  http://sg.danny.cz/sg/sg_io.html
(Sorry, i found no info when exactly this happened.)
The main advantage of using the same device class for Posix I/O and
for SCSI command passthrough was that locking by open(O_EXCL) could
keep burn programs from burning mounted CDs.

The disadvantage came soon later with the extinction of the Big Kernel
Lock. That rather tolerant lock was replaced by a single mutex which
governed all /dev/sr devices together. As result, concurrent use of
ioctl(SG_IO) on different /dev/srN and /dev/srM yielded awful data
throughput until about kernel 5.5.
I created a little temple for this problem and its workarounds:
  https://dev.lovelyhq.com/libburnia/web/wiki/ConcurrentLinuxSr

I was lucky to live with a kernel 2.6 version between both events
for many years. So it lasted until kernel 3.X of Jessie that i had to
revive the use of /dev/sg, which never had the Big Kernel Lock.
Since the kernel version of Debian 10 in summer 2020 each /dev/srN has
its own lock object and the data throughput problems are gone.
(I believe that even that lock is totally unneeded, because both
ioctl implementations of sg and sr do the same. Why should the one
need a lock and the other not ? Cargo cult, i'd say.)


> > Steve McIntyre to debian-user.
> > cdrkit is definitely now EOL, 

> "EOL" is not encouraging.

It is hovering somewhere between this world and the afterworld.
We should not attach unnecessary weights to its feet ...


Have a nice day :)

Thomas