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

[Joerg Schilling]

Jan Engelhardt <jengelh@xxxxxxxxxxxxxxx> wrote:

> >> 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.

Well, Linux offers a generic SCSI (/dev/sg*) transport, so it should be
able to do this in a way that is independent from the SCSI transport.

> >> -	/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?

The drive does not return this information, but the SCSI subsystem creates
these instance numbers. A SCSI drive (like a CD/DVD burner) is supposed to
be known to the SCSI sub-system and thus needs to have a SCSI subsystem
related instance number.


> >> -	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.

Cdrecord is a program that needs to be able to send any SCSI command as 
it needs to be able to add new vendor unique commands for new drive/feature
support.


Jörg

-- 
 EMail:joerg@xxxxxxxxxxxxxxxxxxxxxxxxxxx (home) Jörg Schilling D-13353 Berlin
       js@xxxxxxxxxxxxxxx                (uni)  
       schilling@xxxxxxxxxxxxxxxxxxx     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/