[Libcdio-devel] Re: mmc_get_disc_erasable proposition + questions

[Thomas Schmitt]

Hi,

> Note that there currently are other corresponding wrapper's to MMC commands:
> READ CD, MODE SENSE 6, MODE SENSE 10, SET SPEED, START STOP (whose libcdio
> mmc command name  adds "_media" to the end of the name -- I don't know if
> this was a good idea or not. Thoughts?).

I would reserve
  mmc_<official SCSI command name>()
to functions which very directly perform the
command.
Insofar i am against a general suffix "_media"
to all MMC commands which refer to media.

Each such function should know about the
peculiarities of its CDB.
Nevertheless it is serious work to design an
appropriate prototype of in/out parameters.
How much shall the send payload resp. reply
payload be structured ?
Do we need a pair of
  struct mmc_<official SCSI command name>_cargo {
    ... payload data to be sent exor received ...
  };
and
  int mmc_<official SCSI command name>( ... ,
                                &cargo, &sense);

The struct would encode/decode the data in
components which resemble the terms of the
according SCSI command description.
E.g. for
  int  mmc_read_disc_structure(...)
the structure
  struct mmc_read_disc_structure_cargo {
    ...
    dvd_disc_category; /* Aka: Book Type */
    ...
  }
The function would convert the struct to/from
the byte array that serves as buffer with
mmc_run_cmd().
READ DISC STRUCTURE has more than one cargo
layout. Shall we have more than one structs or
some kind of union ?

(As said: A generic MMC layer is a tricky job.)


What to do with commands from SPC and SBC ?
Shall they be mmc_*() for simplicity ?
(There is no uncoordinated intersection between
 those standards, of course.)


> I have also updated the DVD Book types in dvd.h based on the information you
> cite. I find it however as table 400 rather than 401 (on page 419).

I read in mmc5r03c.pdf :
  Table 400  READ DISC STRUCTURE Data Format (Format field = 00h)
on page 419 and
  Table 401  Disk Category Field
on page 420.

Well, we are close enough with our copies to
verify each others quotations.

------------------------------------------------

> > (Profile would possibly lie in a DVD-ROM,
> >  book type lies if told to do so.
> >  One should use profile if it does not say
> >  DVD-ROM or BD-ROM. Only then one should inquire
> >  DVD Book Type or BD Media Type ID.)
> I welcome suggested code to libcdio to handle this additional complexity.
> Thanks.

The main job for this will be on your shoulders.

You will have to install a new generic media
recognizer which first checks whether it can
get a valid Current Profile by mmc_run_cmd().

If not, then it has to assume CD and make use
of the CD related recognizer in the OS driver.

If MMC profile, then it should be possible to
perform my proposed extra distinction of DVD-ROM
and BD-ROM profiles by MMC command READ DISC
STRUCTURE.
For CD profiles i would advise to continue using
the traditional recognizer (unless it is known
to be buggy).

I can help with the READ DISC STRUCTURE command
at most. See
  http://libburnia-project.org/browser/libburn/trunk/doc/mediainfo.txt
department DVD + BD for type info.
For DVD search
  Disk Category
For BD, first search
  BD-R and BD-RE:
and then
  Disc Manufactuer ID
  
The main task is the re-shaping of libcdio
entrails.

(I'd like to re-iterate my proposal to introduce
 a new table-of-content API function.
 The media recognizer and a contemporary TOC
 retriever would make libcdio ready for DVD and
 BD.
 First task with new TOC is to design the reply
 structure. Some list of sessions and tracks
 would be appropriate.)


Have a nice day :)

Thomas