Re: [Libcdio-devel] Re: mmc_get_disc_erasable proposition + questions

[Rocky Bernstein]

What a rat's nest. Nevertheless, we'll try to make progress here. I don't
expect it will be quick or without error though.

On Sat, Feb 6, 2010 at 9:52 AM, Thomas Schmitt <address@hidden> wrote:

> ...
>
> I would reserve
>  mmc_<official SCSI command name>()
> to functions which very directly perform the
> command.
>

I think so far in libcdio that is pretty much the case.

Insofar i am against a general suffix "_media"
> to all MMC commands which refer to media.
>

Ok. I'll add a new routine without _media and keep the old one in for
backward compatibility but deprecate it over time.


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

Interesting idea. I don't like the suffix _cargo though.
...

> READ DISC STRUCTURE has more than one cargo
> layout. Shall we have more than one structs or
> some kind of union ?
>

A union with a type indicator seems to be a conventional thing to do.


>
> (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'm not against adding something like spc or sbc to the name. If in some
cases a sbc routine does the same thing as a spc routine that's okay and can
easily be handled.


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

It looks then we need to be more explicit about what's meant by MMC-5.


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

If this is ever going to get done, I think you will have to help doing the
READ DISC STRUCTURE part.  In many respects, I am just moderating here as I
really don't have any specific need for any of this. ;-)



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


A safe direction here is to create new libraries for the different standards
or common extensions to existing standards. I don't feel comfortable
violating an existing standard such as say the Philips Red book standard and
modifying or violating it without, however useful, without clear indication.
Both users and application writers need to be aware and transparent about
the fact that an extension on a standard format is getting used.