Re: [linux-minidisc] SCSI support in libhimd

[Adrian Glaubitz <glaubitz@physik.fu-berlin.de>]

On Tue, Jun 08, 2010 at 01:46:54PM +0200, Michael Karcher wrote:
> Am Dienstag, den 08.06.2010, 13:32 +0200 schrieb Adrian Glaubitz:
> > - extend himd_get_discid to cross check disc with discid from SCSI
> >   retrieval
> Why would you want to do that? "Because you can" is not an option.

Hehe, true. But it sounded like a cool feature ;).
 
> If the discid from the Hi-MD medium mismatches the one in MCLISTxx.HMA,
> the Disc is unplayable in Hi-MD equipment and the only way to fix it is
> a reformat. This is because the MCLISTxx.HMA is authenticated against
> data that can only be changed by the formatting instruction or by the
> MCLISTxx.HMA updating stuff. The updating stuff only works if
> MCLISTxx.HMA matches the disc ID in the external area.

But what if the MCLISTxx.HMA gets lost? Is it possible to decrypt the
HiMD audio with just the discid and the keys in the TRKLISTxx.HMA or
is there more magic in MCLISTxx.HMA involved. I just didn't understand
yet why Sony stores the discid in two places. Or is that just for
compatibility with standard MD media formatted as HiMD?

> So, the only thing we gain from cross-checking is being able to tell the
> user that his medium is broken, as the DRM info is inconsistent, but how
> to handle that in our tools? Should we deny access to the data currently
> on the disc? (As it is now, we can read the image from one MD cloned
> onto a different medium, which will fail if we abort on cross-check) Or
> should we just ignore it?
>

Well, I would just tell the user that there's something wrong with the
disc but still offer to retrieve as much music as possible.

> Finally: What do you want to do on images?

Well, I didn't say to remove reading the discid from the MCLISTxx.HMA ;).

> > - move all functions from basictools/himdscsitest.c to libhimd/scsi.c
> Sounds fine.
> 
> > - extend himd struct to include SCSI device information as well
> How do you find out the SCSI device ID for libscg from the path we have?
> I'm afraid we probably need to do that in a platform dependent way,
> which is OK. I suggest to not encourage authors of libhimd users to
> access the SCSI info, but handle it all inside libhimd.
> 
> > - new exports for libhimd:
> >   - himd_format_medium
> >   - himd_erase_medium
> >   - himd_set_time
> >   - himd_get_time
> >   - himd_read_capacity
> >   - himd_eject_medium
> >   - himd_lock_disc(lock/unlock)
> OK, have them fail on images sounds like a good plan. Or should we drop
> image support?

No, keep image support. I just want it to be renamed to "Open
directory" or "Open image" instead of "Connect" since once HiMD auto
detection works on Windows, MacOS and Linux, the name would be
misleading. I was already thinking about integrating support for
actually opening pure dd images in QHiMDTransfer so an "Open HiMD
image" menu option would actually make sense. But I think that would
just makes things too difficult. Or we integrate a function to backup
HiMDs into images, then this would make sense again:

File->Open HiMD backup image

and

File->Save HiMD to backup image

Actually, I start liking this idea. What do you guys think?

> > The most important point in this discussion will be the decision how
> > we integrate libscg into our tree. Should we opt for an external
> > dependency or should we include a fork into our tree?
> As there are no prebuilt libraries of libscg, our users have to compile
> it anyway, so it can be as well in our tree. This also makes it possible
> to integrate the Mac patch to recognize "hard drives". When distributing
> a patched version of libscg, please read the License before. IIRC it is
> required that we change all modified files to indicate they are
> modified, i.e. don't return "schily" as author.

Ok, I think I should get in contact with Joerg. But I was also
thinking about creating a folder where people will have to drop the
cdrtools source before building. But let's discuss with Joerg
first. Maybe I can convince him to integrate the Mac patches. At least
the one that modifies "/opt/schily/include/schily/xconfig.h" makes
sense since otherwise it's not possible to build external code using
libscg outside the cdrtools tree.


Adrian