[Libcdio-devel] Re: Submission of new mmc function for libcdio

[Thomas Schmitt]

Hi,

> Frank: I hope we haven't lost you here. I think we still are interested in
> the feature you suggest.

Didn't you announce that you accepted
mmc_get_disc_erasable() already ?

Did i miss a new proposal of Frank ?


> > is there
> > really no profile retriever function yet ?

> No there isn't one. In libcdio's src/util.c you'll see for example a MMC
> call to GET CONFIGURATION.
> I am undecided on whether to add one.

Profile is the most general first hint about
what media you have and what you might expect
from it. In my eyes it is very important.

After all we have a list of profiles in the
libcdio glossary now. This wakes wishes. :))


> Consider this code from libburn's mmc.c
>     if (d->current_profile == 0x1a || d->current_profile == 0x13 ||
>         d->current_profile == 0x12 || d->current_profile == 0x43)
>         d->status = BURN_DISC_BLANK;

This forces the overwriteable media into the CD
inspired model of Blank, Appendable, Closed.
"Blank" means writeable from scratch.
"Appendable" means writeable from a non-zero
address, which one has to inquire from drive.
"Closed" means not writeable.
The test looks for DVD+RW, formatted DVD-R,
DVD-RAM or BD-RE.
libburn sees them as always blank. Quite an
internal gesture, indeed. It does not use the
API but digs in burn_drive entrails.

Nevertheless, the application may inquire the
profile in order to decide what to do next.
Those media may well contain readiable data
although in the coarse write-oriented 
classification they are regarded as blank.


There is one more candidate
  0x42 "BD-R random recording"
but that is not supported by libburn (neither by
my BD burner).
At least one can tell the user what it is
and why it is not supported.

(It would be an overwriteable media that
 shrinks with every block you overwrite.
 Weird.)


> This is exactly the knowledge I think would be helpful to have encapsulated
> in a library. That is, in order to determine if a disc is blank:

MMC is a multidimensional potato (more nicely
called a manifold). There are so many partial
views and classification scales.

There are other dimensions like whether a media
allows to burn a track without knowing its size
in adavance (TAO-like versus SAO-like).
Or random-access read-write, or formattability,
or blankability.

These classifications do help with handling
media, but they also obscure the actual info
about the currently loaded media.


> That said, I think it useful to make it easy to issue some of the
> lower-level or more MMC-specific commands that often have to be run in order
> to answer the higher-level questions.

The interface will be a demanding task. How
much detail shall be exposed to the caller ?

The architecture of libburn cannot be a good
example as it heavily copies MMC info into its
burn_drive object for later inquiry by the
API calls.


My team mate Mario Danic told me that he is
working on a MMC library. We sketched roughly
that it could replace one half of our current
MMC/SPC/SBC code and would swallow our system
adapters.
The other half of the current MMC code would
become part of the burn_drive methods.

Maybe you can share thoughts with him about
the protoypes of a comprehensive MMC interface.

It should be more convenient than raw
mmc_run_cmd() and keep the caller from doing
obviously inappropriate things.
On the other hand its doings should still be
recognizable in MMC specs. No abstractions.

If you start a common effort then i would be
your first user. :))


Have a nice day :)

Thomas