Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt <jengelh@linux01.gwdg.de>]

>> This are the three most important Linux kernel bugs:
>> 
>> -	ide-scsi does not do DMA if the DMAsize is not a multiple of 512
>> A person who knows internal Linux structures shoule be able
>> to fix this (and allow any multiple of 4) in less than one hour.
>> If we sum up the time spend on this discussoion, I really cannot
>> understand why this has not been fixed earlier.

Unfortunately, ide-scsi is deemed obsolete in 2.6, so it looks like no one 
seems to be willing to do that. About 2.4 I'm just as unsure, because it's 
in it's way to deep freeze. It might go through as a bugfix, though.

>> -	/dev/hd* artificially prevents the ioctls SCSI_IOCTL_GET_IDLUN
>> SCSI_IOCTL_GET_BUS_NUMBER from returning useful values.
>> As long as this bug is present, there is no way to see SG_IO via
>> /dev/hd* as integral part of the Linux SCSI transport concept.

Now you're talking shop ;-)

Hm, this ATAPI stuff makes me a headache. Well, anyway, out of 
curiosity, what is an ATAPI drive (IDE-ATAPI) supposed to return when asked 
for bus number, id or lun - independent of OS and/or cdrecord?

>> -	If sending SCSI sia ATAPI, Linux under certain unknown conditions
>> bastardizes the content of SCSI commands. A possible reason may be
>> that it sends random data in the remainder between the actual SCSI
>> cdb size and the ATAPI SCSI cdb size.

Not so good (the content freakup). IMO, if one can play around with the 
scsi tunnel (SG_IO) from userspace, commands should get through unmodified.
If it's not cdrecord/libscg making my writer do coffee, it must be this 
modification step.

> I think it might also be useful to make a list of all the SCSI commands that
> cdrecord uses. Including all the vendor specific ones. One could then verify
> that the Linux kernel is passing them onto the device correctly.

Or not, for that matter. There is surely a reason for the OS to do 
something to userspace-provided SG_IO packets to prevent the worst.


Jan Engelhardt
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/