Messages in this thread |  | | | From | "D. Hazelton" <> | | Subject | Re: CD writing in future Linux (stirring up a hornets' nest) | | Date | Sun, 19 Feb 2006 20:53:24 -0500 |
| |
On Sunday 19 February 2006 04:20, Matthias Andree wrote: > On Sat, 18 Feb 2006, D. Hazelton wrote: > > At this point I seem to have stumbled across a document that has what > > Joerg might be looking for Linux to introduce. It's available at t10.org > > and is a translation layer specification for OS's to use if they want to > > access ATA devices like SCSI ones. > > Is that something other than CAM? If so, please mention the exact > document name.
The documents title is: "Information Technology - SCSI / ATA translation (SAT)
The revision I'm looking at is R08 - the most current I could find. I'll have to dig, but it doesn't appear to just be a rewrite of CAM from the quick once over I gave it.
> > Seems to me this wouldn't be a good or bad thing to add to the kernel. > > The > > Well, such an integration must avoid: > > - breaking existing conformant applications, where conformant here would > apply to existing interface documentation such as the SCSI General > Programming HOWTO from torque.net. > > This means that int fd = open("/dev/foo", O_RDWR, 0); > int e = ioctl(fd, SG_IO, &cmd_block); > needs to remain functional. > > - duplicating code which would cause immediate bit-rot...
Yes, true. After all Linus has said that there is to be no more breaking of userspace interfaces. In this case I think what the layer would do is allow the people that want to to use /dev/sg* to access all SCSI and ATA devices on a given system.
It's purpose, from the blurb on t10.org, is to provide a SCSI interface to ATA disks for people that want to access them that way.
> > problem is that introducing the layer and thereby unifying the SCSI and > > ATA busses into one namespace is a big task. > > ...so it could really only be an interface layer on top of existing > interfaces to avoid that. (Any other opinions?) >
Right. Which is one reason why I did say that I thought it might be a good idea, but didn't think that anyone would bother. I also don't think it's really necessary. SG_IO happens to work great and the amount of work involved...
Anyway, to me it seems like it'd just be resurrecting a deprecated module and expanding it so it has a wider scope. Only real difference would be that it wouldn't take devices from their driver, just provide a second interface to it - which also means that all the ATA drivers would need to have hooks that it could call into. (Or am I over thinking it here?)
> And then that interface would only be sensible if it actually improves > the situation, for instance, if applications gain source-level > compatibility with NetBSD or FreeBSD.
Well, FreeBSD implements CAM, so if someone implemented CAM that'd provide source-level compatability. In this case what it would do is hard to say - the only thing I can think it _might_ do is quiet a couple of people down a bit.
> I think libata's integration of parallel ATA is already going a way that > leads to unifiying all the layers. For disks, the sd driver is used with > libata. I'd be surprised if it wouldn't work for CD/DVD drives, too, at > least in the long run.
Ah, yes. I was under the impression that libata only handled PATA and SATA - is it going to be expanded to encompass the entire ATA bus?
> Part of the problem is Jörg's expecting a solution the day before > yesterday.
Well, from some comments he made in private mails he seems to think he was promised (by Linus, no less) that the DMA problems in ide-scsi were going to be fixed. Instead the module was deprecated and SG_IO was introduced - this seems to be one of the things he's been angry about.
DRH - 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/
|  |