Hi, > 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 example/mmc2.c 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 :) Thomas
