[Libcdio-devel] Re: Using major/minor device numbers to determine SCSI or ATAPI

[R. Bernstein]

As usual Steve Schultz has made some rather good points, but problems
with gnu.org's mailing list has prevented him from posting them. They
are at the end of this post (if it gets through).

Rather than respond inline I'll try to summarize the state of using
cdparanoia's device/major code and how this may impact not just
libcdio's paranoia but libcdio in general.

libcdio's cd-paranoia right now has just gotten started so I'm not
really trying to diverge too much from the existing interface or API
or improve it. (On the other hand if someone is interested in
improving things -- and there's much room for improvement -- I welcome
this and a branch can be made.)

Internally I simplified the code, partly because it now uses
libcdio. And I removed some things from a public structure that
probably shouldn't be there (and may have added others like a cdio
pointer).  I may have chopped out too much or maybe not -- perhaps I
just chopped some of the historical- or special-case code or code that
should be done some other way if it is important. I did leave in the
GNU/Linux device major stuff.

A couple people have had problems with libcdio's cd-paranoia on
GNU/Linux because they had SCSI-encapsulated drive presumably for
cdrecord.  This caused libcdio's paranoia to erroneously think a drive
big endian, but I can't say it was caused by the the device/major code
(as opposed to some other code that was removed).

cdparanoia's automatic detection of drive endianness by doing a
Fourier analysis seems to work reliably, but it does cause a bit of
noise, delay, and CPU cycles on startup. (Mplayer uses cdparanoia for
CD-DA reading so I suppose it can be annoying there when one just
wants to play a track)

Given what's been reported, probably I don't want to add in the
complexity that was in cdparanoia for drive-endian determination on
other OSs. And looking at say some OSX and FreeBSD ports of
cdparanoia, I none have retained this part of the code either. In
fact, I may remove GNU/Linux device/major if it messes up. There are
and always have been options (-c, -C) to force drive endianess.

However for myself, it is nice to have a plan or scheme of how
something like as drive endianness should be dealt with even if it is
not implemented right now (or in the near future). My current thought
is to have a mechanism whereby a person can specify a CD-ROM's
characteristics. cdparanoia has an array of a C structures. xmcd also
has this and what's nicer about this is it is more like a CDDB cache
text file, where a user might have one and there might be a
system-installed one or one that gets distributed with libcdio.

I'm not interested in trying to catalog all sorts of CD-ROM drives
that were ever made and all the quirks they might have. Instead this
table would basically contain things to keep libcdio from
misfunctioning without adding complex internal code for say drive
endianness. And to reduce the size of this table, one might imagine
that we assume little endian to be the default since that seems to be
the majority and only note those few CD-ROMs that are big endian that
folks using libcdio experience.

I've also noticed that there are generally multiple ways to issue
commands, say either by MMC (SCSI passthrough) or the OS
(e.g. "ioctl") way, or the 6 vs 10 byte MMC commands or "get
profile/feature" vs. "mode sense". Over time, some of these things
might make there way into this file for certain CD-ROMs and OS
pairs. (The libcdio access-mode thing in libcdio is a bit of a crock
and it just hasn't panned out the way I and prossibly hvr - who
engineered it - thought it might.)

Finally, yes, if cdrecord has figured out a way to tell if a drive is
MMC-2 or MMC-3 compliant, it might be a good thing to add -- *if* it
doesn't add too much complexity and solves a problem that users
encounter. I'm not sure right now it addresses drive endianness as I
don't recall any SCSI/MMC document saying for *audio* track data
whether a particular order is specified.

Steve's post is below...
- - - - - -

On Fri, 29 Apr 2005, R. Bernstein wrote:

> Don't know squat about PCM data. Is that stored as audio-format tracks

        Well, what'd  you think audio tracks on a CD were - MP3? :-) :-)

> rather than mode 1 or mode 2 which has error correction? If so, it

        Mode 1 I think - the M2F2 is without error correction (for VCDs)
        as I recall.

>  >    Ah ha!  I think you're on to something there.  It might be that MMC
>  >    drives pass the data thru without the byte flipping that some of the
> 
> Probably that's the problem that cdparanoia is addressing. 

        Ok - and that goes along with ...

> First there's the "If so" part that I don't really now. As for the "is
> it worth worrying about" part, well if libcdio's cd-paranoia is to be

        The "if so".  IF the oddball/proprietary logic in cdparanois is
        historical cruft from a bygone era then perhaps now is a good
        time to leave it behind.  It'll probably never go out of cdparanoia
        simply because software never shrinks/de-bloats ;)

> correctly by cdparaoia. This came up not as an academic excercise but
> because someone on GNU/Linux had SCSI emulation of an ATAPI drive. In

        If there's a bug in the GNU/Linux SCSI emulation then some 
        "#ifdef __linux__" code will be needed but...
        in general , to get back to the original question (or part ofit) -
        it apparently is not portable to use the major/minor device 
        numbers to gauge the capabilities or data format of a drive. 

        It might be possible, by looking at the cdrecord/libscg code,
        to determine if a drive is MMC capable or not.  For example if
        I run "cdrecord -v dev=/dev/rsr1c:@,0 -prcap" on a system at work
        there's a lot of info, one line of which is:

        Device seems to be: Generic mmc2 DVD-R/DVD-RW.

        so cdrecord seems to be able to tell if a drive is MMC-2 or 3 or
        not MMC...

> I don't have enough experience past or present to know.  cdparanoia
> contains a drive-exceptions list that hasn't been ported in libcdio.

        I have some experience -  SCSI optical drives are becoming quite 
        rare and getting expensive (low production volume).  I haven't 
        seen a SCSI DVD writer, for example, at all with the exception of 
        a $3-4K authoring drive (can write authoring/mastering media that 
        regular drives can not).

        Seems that continuing research is needed to figure out what's going 
        on and the best way to deal with it.

        Cheers,
        Steven Schultz