Re: cdrecord hangs my computer

[Douglas Gilbert]

Linus Torvalds wrote:
> On Sat, 6 Dec 2003, Wakko Warner wrote:
> > >
> > > One is just plain confusion - anybody who uses cdrecord has
> > > either been
> > > confused by the silly SCSI numbering (while "dev=/dev/hdc" is not
> > > confusing at all, and uses the same device you use for
> > > mounting the thing etc).
> >
> > Actually, it would be nice if I could use dev=/dev/scd0.  I
> > do have a scsi burner (and an ide one too)
>
> It _should_ just work these days. Anything that uses "cdrom_ioctl()"
> should automatically get the SCSI command translation code (which
> isn't part of the scsi driver).

Yes dev=/dev/scd0 should work for "real" SCSI (and USB, IEEE1394
and sATA [via libata] attached) cd/dvd players in lk 2.6.
Copying the SG_IO ioctl and friends into the block
layer isn't exactly pretty in lk 2.6. No doubt I'll be hearing from
the author of cdrecord about some of the rough edges. Basically
cdrecord is tricked into believing it is talking to an sg device.

One rough edge is cdrecord's use of the SCSI_IOCTL_GET_IDLUN ioctl
which encodes bus/channel/target/lun into an integer. cdrecord
uses this for its dev=<n,m,q> notation. The drivers/block/scsi_ioctl.c
implementation returns 0 in all cases. So if you have 2 or more
ATAPI cd/dvd burners cdrecord's dev=<n,m,q> usage won't be able
to differentiate.

ide-scsi has always had problems (I spent about a week on it
and gave up with only a few minor fixes to report) but it
may be a useful "insurance" driver to keep around in lk 2.6 .
[It is also needed for ATAPI tapes so its deprecatation
warning might like to take into account the peripheral device
type.]

Yes the bus/channel/target/lun notation is dated but it has been
in place for around 15 years (in the Sun's bus/target/lun form).
These days the "bus/channel" component is defined by the host OS,
the "target" by the transport (see "object identifiers" in SAM-3
Annex A). Only the "lun" is defined within the SCSI^H^H^Htorage
Architecture Model (SAM-3 section 4.9 in the latest draft).

> But hey, the scsi layer confuses me. Less than it used to, but still.

Well making the scsi layer handle some of the the most
sophisticated storage devices and some of the most brain
damaged at the same time is proving quite a challenge.
With libata (and later SAS) sATA disks will be getting to
the application space via the sd driver. And how will
object storage devices fit into Linux's block-centric I/O
architecture?

Doug Gilbert


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/