[Top][All Lists]

[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: Thu, 28 Jan 2010 11:13:56 +0100


> Frank kindly offers a possible implementation that works without needing
> SCSI sense data which isn't universal in all the libcdio drivers yet. And it
> sounds like Thomas may have thoughts on how (in some cases?) one might do
> better when one has SCSI sense data.

My only doubt is about the case of error.

Frank: did you see a case where the outcome was
"erasable" despite error indication ?

Maybe one should just decide "not erasable" in
case that mmc_run_cmd() returns error.

When implementing a fetcher for the erasable bit
then one should consider to also make API calls
out of
which among others retrieves profile numbers.

Profile number and eraseable bit cover the same
info, but in -ROM drives they might contradict.
A "CD-ROM" that is "erasable" might indeed be
a CD-RW in such a drive.


More detail about error handling:

I assume that in most cases of error one just
sees the unaltered buffer content. So the
caller defines its own default value.

But without the sense reply one relies on what
the operating system did to the read buffer
before it detected failure.
Although it is plausible that the buffer stays
untouched, this is still an unportable guess.

The sense data would tell why failure happens.
The error outcome of mm_run_cmd alone is only
an indication that not everything went well.
I would pick only a few sense codes which allow
to regard the buffer content as valid.
In all other cases i would return error resp.
the default value.

So maybe it is easiest to just fallback to
"not erasable" if the reply smells fishy.

> So Thomas, would you suggest an implementation of mmc_get_disc_erasable()
> that works whether SCSI sense data is available and falls back to what Frank
> suggests if not?

The fallback is already built-in in libcdio.

If the OS driver does not forward the sense
bytes to the libcdio API, then the caller
will get told that there is no sense reply.
Not nice, but easy to handle: "Unknown error".

Have a nice day :)


reply via email to

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