Messages in this thread | | | From | Joerg Schilling <> | Date | Mon, 30 Jan 2006 12:43:59 +0100 | Subject | Re: CD writing in future Linux (stirring up a hornets' nest) |
| |
Jan Engelhardt <jengelh@linux01.gwdg.de> 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@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |