> Hi Gerd!
>
> Could you check for me in the SCSI standards what _must_ be supported for
> a CD-ROM drive? I don't know where they hide the specs on SCSI... Anyway,
> I just checked the ATAPI spec, and it specifies that _ALL_ ATAPI drives must
> support CDROMREADRAW (via the READ-CD packet command), CDROMREADMODE1,
> and CDROMREADMODE2. Support for CDROMREADAUDIO (reading raw CD-DA via the
> READ-CD packet command) is listed as optional. (page 144 of ATAPI 2.6)
> I notice that CDROMREADRAW is included in sr_ioctl.c; is this capability
> manditory?
scsi-3 mmc lists READ-CD as mandatory (and my copy of the driver already
has support for it added).
Old (guess most existing) drives are handled completely different: By
switching the block length to 2336/2352/whatever with MODE SELECT and
using the normal READ(6) or READ(10) command. The standard says nothing
about what should/may not work. Much ist vendor-specific there, scsi-2 is
just to old. I know that there are drives which do _not_ support 2352
bytes blocksize (no CDROMREADRAW), but 2336 (CDROMREADMODE2) works fine.
> It seems that if SCSI supports CDROMREADRAW as manditory, like ATAPI
> does, then we could just drop CDROMREADMODE1, CDROMREADMODE2, and
> CDROMREADAUDIO, and still have the exact same functionality.
Think we can drop CDROMREADMODE1 without upsetting anyone. But we can't
drop CDROMREADMODE2 (existing programs use it + see above). Not sure about
CDROMREADRAW.
> People could read all the photo CDs, video CDs, or whatever they wanted
> but they would want to first check the type of the CD's sectors (with
> something like the CDROM_DISC_STATUS ioctl, or just doing the checking
> themselves).
BTW: there is a design flaw in CDROM_DISC_STATUS: A CD-ROM can have
different sector types in different tracks. Examples are Mixed Mode CDs
(data+audio) and video CDs (one small track XA mode1 with a iso9660 fs,
holds Win* player software, one big track XA mode2 with the mpeg data).
> I would then integrate CDROMREADRAW into the Uniform CD-ROM driver
> (there is a commented out stub there now) to provide common error
> checking and behavior. I think it would be the Right Thing (tm). What
> do you think?
Another way would be to design a new ioctl for the READ CD command,
allowing a program to do all sorts of sector reads (with/without ecc,
subchannels, ...), allow to read more than sector at once (does _not_
work with the current CDROMREADMODE2, you need one ioctl per sector).
Interface could look much like the current CDROMREADAUDIO ioctl: you pass
a struct with lba, # of sectors, buffer pointer, and some flags telling
what you want to read.
CDROMREADMODE2 compatibility could be handled completely inside the
generic cdrom driver.
Gerd