Re: cdrecord hangs my computer

[Jens Axboe]

On Mon, Dec 08 2003, Douglas Gilbert wrote:
> 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.

It's not tricked, cdrecord should not care about device type. All it
needs to care about is SG_IO working or not.

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

Not sure I see any merrit in supporting that at all, but if so it would
be pretty easy to fake these.

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

It does, the 2.6 warning printed is just for CDROM devices.

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

What makes you say that Linux has a block-centric IO architecture? 2.6
block io layer is quite happy to do byte-granularity SCSI commands for
you.

-- 
Jens Axboe

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