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

[Rocky Bernstein]

On Sat, Jan 30, 2010 at 12:34 PM, Thomas Schmitt <address@hidden> wrote:
...

> Did i miss a new proposal of Frank ?
>

See the last paragraph of the original top post.


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

I think a mmc library is needed and that's why I started mmc.c  over 6 years
ago. It is bundled into the libcdio library, because it is not all that
extensive (in fact in some ways it is still lame) and because of the
affinity to OS drivers.

It is conceivable that if there were a separate mmc library with drivers for
each OS (or in some cases more than one driver per OS), then libcdio could
use this library as a "mmc" driver much in the same way libburnia uses
libcdio as a possible backend.


> It should be more convenient than raw
> mmc_run_cmd()


See for example the 3 mmc_mode_sense commands.

and keep the caller from doing
> obviously inappropriate things.
>

That is for example why mmc_get_cmd_len() was created.

On the other hand its doings should still be
> recognizable in MMC specs.
>
No abstractions.
>

I'm not sure I agree with the no abstractions part. I suppose it depends on
what one calls an abstraction. Is mmc_get_cmd_len() an abstraction? Is
mmc_mode_sense() which may select either the 6-byte or the 10-byte version
depending on which works an abstraction?

But since this imagined mmc library is currently vaporware, I don't it worth
discussing -- in the abstract ;-)

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

Or rather libburn and libcdio would.

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