[Paranoia] copy protection

[pjones]

On Wed, 2005-01-19 at 14:39 +1000, Douglas Gilbert wrote:

> > In general, sg and ide-scsi are the way of the past, and need to be done
> > away with in a very serious way.
> 
> The sg driver is there to keep disk, tape and cd/dvd
> drivers honest (amongst other things). If the policy
> or implementation of a driver (e.g. cdrom) impedes an
> application writer from doing want they want, then the
> application writer should have a lower level and more
> direct route to the device (i.e. a _clean_ pass
> through).

Absolutely.  Granted, I think both of these are bad answers for that;
that's why I put a lot of work into making Jens Axboe's bsg driver
usable for these purposes.  Unfortunately, it hasn't gone into the
upstream tree because of some painful issues on multiarch systems (i.e.
sparc64, ppc64, s390x, etc).  Nevertheless, in principle we agree that
there's got to be some mechanism for doing this.  Right now, the best
choice in cdparanoia seems to me to be SG_IO on a normal block device.

> The SG_IO ioctl in the block layer has been and remains
> inferior to the SG_IO ioctl in the sg driver.

In what way is it inferior?  I haven't ever seen anything seriously
different in a way that cdparanoia should care about.  If there is
something, please, tell me?  A way to reproduce any such case would be
very helpful.

> I am working on improving that (currently in the area of
> interference on error paths) but I doubt some policy
> issues will ever be resolved.

You've mentioned "interference on error paths" and the like before, but
as far as I can tell we always get pretty reasonable errors doing SG_IO
on the real device.  What can I do to reproduce a case where I get
incorrect errors?

> We will continue to maintain the ide-scsi driver as there
> are still some situations where it is needed.

As well you should; I just don't think cdparanoia should be one of those
situations at this point.

> The problem reported by David Wake in the "Cdparanoia
> stuck in blk_execute_rq" thread looks like a device
> lockup (/dev/hda) which never clears (and prevents
> further resets being done). If sending a device reset
> via the a block layer ioctl (borrowed from the sg driver)
> has any better success in the same situation then that
> is a bug that needs to be fixed in ide-scsi.

I think it's actually the block layer getting confused when we do a
reset and then send a TEST UNIT READY too soon.  But I haven't read all
of that code on the kernel side in quite some time, so I could be wrong.
Anyway, I'm pretty sure the current code in cdparanoia (probably in both
the svn version and the RH package) is doing this all wrong.

-- 
        Peter