libcdio-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Thomas Schmitt
Subject: [Libcdio-devel] Re: Submission of new mmc function for libcdio
Date: Sat, 30 Jan 2010 22:19:42 +0100

Hi,

> > Did i miss a new proposal of Frank ?
> See the last paragraph of the original top post.

Ah yes. That was quite out of my own scope.
Therefore i forgot it. Selective amnesia.


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

I could imagine that the MMC library has a
generic MMC layer and an OS related layer.
The latter would be implemented by system
adapters of libburn resp. mmc_run_cmd()
of libcdio.
One could consider to merge the OS interfaces
of libburn and libcdio, but actually their
differences might become valuable at some point.
E.g. for debugging.
(We also run less risk to break applications
 by fixing valuable bugs.)


> That is for example why mmc_get_cmd_len() was created.

I would expect that the MMC layer composes CDBs
and interprets sense replies.
It should also negociate the reply size of the
commands which have no fixed size. (Send a first
command with small Allocation Length and learn
the real Allocation Length from the truncated
reply. growisofs wisdom.)


> I'm not sure I agree with the no abstractions part.

I mean that it shall restrict its model strictly
to the MMC terminology and not try to invent own
concepts.
As much 1:1 as possible. One call for one MMC
command.
But completely isolated from OS specifics
and filling in automatically anything that is
determined already by the variable parameters.

To determine those real parameters is the most
demanding work with that design task.


> Is mmc_get_cmd_len() an abstraction?

In my idea of the MMC software layer it is rather
a part of its entrails. Hidden by encapsulation.
But still available for direct use of
mmc_run_cmd(), of course.


> But since this imagined mmc library is currently vaporware, 

It depends on whether you and Mario would find a
consensus about the prototypes. Implementation
would be quite straightforward. Applications
would be ready to jump on the train from start.

One would have to push a bit :))


> > i would be your first user. :))
> Or rather libburn and libcdio would.

Yeah. But in libburn i would implement its usage
and then test it with my backup runs.
If they say it is ok, then it can hit the public.


Have a nice day :)

Thomas





reply via email to

[Prev in Thread] Current Thread [Next in Thread]