[Debburn-devel] Re: Problem recording with new system

[Peter Samuelson]

[scdbackup at gmx.net]
> As sr on kernel 2.4 does neither work for SG_IO nor obey O_EXCL
> one has to continue support for sg.
> On 2.6 we usually had /dev/hdX as address. But the new SATA
> devices raise the sg-sr issue again.

We want to move away from sg.  With modern kernels we can pass SCSI
commands directly to /dev/hda or /dev/scd0 and those are much more
intuitive for users to use, since it is the user-visible device name:
what they use to mount their CD-ROMs, what shows up in kernel error
messages, etc.

Speaking of which, by the way, I suggest moving away from /dev/srN as
well - as the kernel devices.txt registry says, "The prefix /dev/sr
(instead of /dev/scd) has been deprecated."  This doesn't matter all
that much - everyone always seems to provide sr0 -> scd0 symlinks.  But
/dev/scdN has been correct for many years now.  (I do still find myself
saying "/dev/srN", mind you.)

Kernel 2.4 users can keep doing what they have always done, using SCSI
bus addressing like God^WSchilling intended.  I don't consider it much
of a priority to convert users from "dev=0,3,0" to "dev=/dev/sg1".
Both of those are a horrible thing to do to the users.  If someone
wants to write support for taking /dev/scd1 and doing 'modprobe sg' and
scanning /dev/sg* until it is discovered that the same device is
/dev/sg2, that's fine - that is what I think Schily should have done 10
years ago.  But today, kernel 2.4 is a dying platform, so I myself am
not interested in writing that code.


> The only known obstacle for kernel 2.6 sr in libburn is
> ioctl(CDROM_DRIVE_STATUS). But its purpose is to
> distinguish sg CD drives from other sg devices - the same
> is supposed to be already done by the device classification
> as sr (and not sd or st).

This should not be an issue, as /dev/scdN _only_ refers to optical
drives.  sg is a bit of a mess here, as it's normally not user-visible
and it's not at all obvious, from a user perspective, how to map
devices to sg numbers.

> In order to get full locking compatibility with libburn or growisofs,
> wodim should in this case translate dev=/dev/sgN into /dev/srN
> internally.

First, I suppose you already know this but sgN does not map to scdN in
the general case; if you have tape drives or scanners the numbers will
be different.

But really, if we ignore /dev/sg as much as possible, eventually it can
just go away.


> What is the best criterion to tell kernel 2.4 from kernel
> 2.6 ? (Or better: to tell good sr from bad sr ?)

I guess you can try the SG_IO INQUIRY ioctl.  You're probably already
using that ioctl later, right?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/debburn-devel/attachments/20070228/22726ed7/attachment.pgp