Re: copy protection

Peter Jones wrote:
> On Tue, 2005-01-18 at 09:18 -0700, Aaron Birenboim wrote:
> 
>>I have some disks which I cannot rip.
>>This is a new experience for me.
>>
> 
> 
> What CDs?  And how do they fail to rip?  What does cdparanoia say?
> 
> 
>>xmms seems to be able to play them.
>>
>>I am running 2.6 kernel, and using the IDE-ATAPI device.
>>
>>Will it help me to go to SCSI-generic emulation on
>>the 2.6 kernel?  (I thought 2.6 improved IDE, so that
>>was not necessary)
>>Do I really have to remove IDE-ATAPI from 2.6 kernel
>>to get this to work? (Can I just load a SCSI-generic module
>>and use /dev/sg2?)
> 
> 
> At the moment, it unfortunately depends on where you got cdparanoia.  If
> you're using my packages from Fedora Core 3, then you should be able to
> have /dev/cdrom be a symlink to /dev/hdc (or whichever device is your cd
> drive) and it will Just Work.
> 
> Unfortunately, I haven't merged that code into the svn repo for
> cdparanoia yet, or done a release with it, so I don't think other
> distros are using that yet.
> 
> 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).

The SG_IO ioctl in the block layer has been and remains
inferior to the SG_IO ioctl in the sg driver. 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.

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

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.

Doug Gilbert