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

[scdbackup at gmx.net]

Hi,

> 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.

What i have in mind (and reversely implemented in libburn)
is a translation which obtains the SCSI address parameters
Host,Channel,Target,Lun of the given /dev/sgM and
then iterates over the /dev/scdN devices to find the
one with matching address.
Address parameters obtained by ioctl(SCSI_IOCTL_GET_IDLUN).


Eduard Bloch, Andy Polyakov and me once discussed the
O_EXCL issue, found it quite messy and each went to more
amusing topics.
I then believed that /dev/s* would be restricted to
old ide-scsi and not-so-mainstream drives. But now
libata (?) brings sg/sr/scd back into the mainstream.

A standardized effective device file address for wodim
would guarantee locking against other instances of wodim
with dev=Bus,Lun,Target, dev=/dev/sgN, dev=/dev/scdM .
This is a property which i deem valuable in libburn.
If we would coordinate the choice of the device path
then we would get mutual locking of wodim and libburn
(as we have with kernel 2.4 and /dev/hdX on 2.6).


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

I now consider to re-activate libburn's SCSI sibling
sweeping swipe. Implemented for kernel 2.4 but useless
with my SuSE 9.0 because only sg obeys O_EXCL.

This gesture keeps open O_EXCL all 
"/dev/sr%d", "/dev/scd%d", "/dev/st%d", "/dev/sg%d"
which have matching SCSI address parameters.
If any of them fails with EBUSY then the drive is not
allowed to be used.

Nevertheless one can still circumvent this with self-made device
files or with permission settings which differ from sg to scd. 

So a standardized effective drive address path would
still offer benefits. For libburn this makes it much harder
to circumvent its own O_EXCL locking.
Finally libburn is willing to open /dev/hdX or /dev/sgN and
absolutely nothing else. Links, device file clones,
SCSI siblings, everything has to meet there.
That way cdrskin is able to accept dev=/dev/sr0 even on
kernel 2.4 systems.

I would change libburn to use /dev/scd* rather than /dev/sg*
on systems where wodim is committed to use the same.


> I guess you can try the SG_IO INQUIRY ioctl.  You're probably already
> using that ioctl later, right?

It is one of the queries made during libburn drive scanning.
Currently libburn uses a 00h TEST UNIT READY to check readiness
for ioctl(SG_IO). But 12h INQUIRY would be ok too, i guess.


So one would first try to find any workable /dev/scd and then
decide wether to list /dev/scd or /dev/sg with option --devices ?


Have a nice day :)

Thomas