mmc_get_discmode (Was Re: [Libcdio-devel] Re: Submission of new mmc function for libcdio)

[Rocky Bernstein]

On Thu, Jan 28, 2010 at 5:43 AM, Thomas Schmitt <address@hidden> wrote:

> Hi,
>
> > Yes, I think libcdio should have a mmc_get_discmode, so additions are
> most
> > welcome here.
>
> GET CONFIGURATION produces quite a fat result.
> Probably one would need more than one API
> call or a fat structure to exploit it.
>
> One should make a list of items which are of
> interest (or define the fat structure which
> swallows all).
>

SCSI MMC's GET CONFIGURATION may make sense from the standpoint of defining
a hardware interface, but it doesn't make sense from a programming
standpoint. One purpose of a library is to bridge that gap.

What we've seen in the past from the standards is that there are these big
broad interfaces - MODE SENSE with the mode pages are another example using
a slightly different interface. And then since there are now two or 3 ways
to get the same information, the programmer is left in befuddlement trying
to figure out which one or combination of these to use.

So let's not go down that route. As a fall-back position, there is a general
way in libcdio to get the lower level detail. But what the library should be
providing is a way to get the useful bits of information without having to
understand the history of the standards, drive conformance (or not) to this,
or the idiosyncrasies of the standards.

In libburn i pick some info and store it in the
> burn_drive object. Much info is ignored, though.
>
>
> > I had thought recent work that Thomas added here covered this, but I
> don't
> > see it. Perhaps I was thinking about information he recently added to the
> > libcdio glossary under "Media models and profiles" which may be of some
> > help?
>
> I listed the profiles in the gloassary, yes.
> But since libburn does everything via its own
> MMC commands i did not implement any new API
> calls which use mmc_run_cmd().
>
>
> libburn has a call
>  int burn_disc_get_profile(struct burn_drive *d, int *pno, char name[80]);
> so how about
>  int cdio_get_profile(CdIo_t *p_cdio, int *pno, char name[80]);
>

Something like this would be fine.

I looked at  the doxygen comment for this and the implementation. Is it true
that name is just a character interpretation of the value of pno?

If that's the case, then why not just have a function to map the number into
its corresponding string?

>
> (or the fat struct and a single call ?)
>
> libcdio may copy function
>  char *mmc_obtain_profile_name(int profile_number)
> from libburn/mmc.c which translates numbers to
> names.
>

 libcdio already has this. However it was a while since I last updated it
and have copied newer profiles numbers and strings from libburn. It looks
though as there are some number/strings in libcdio that are not in libburn.


>
> Have a nice day :)
>
> Thomas
>
>
>
>