On Sun, 2008-12-07 at 02:19 +0300, Sergei Shtylyov wrote: > Hello. > > Alan Cox wrote: > > >> Oh, yes. SCSI emulation is just what Linux embedded world is asking > >> for... > >> > > > > Well ATAPI is SCSI emulation (its a sort of pidgin SCSI admittedly). > > > > ATAPI is SCSI transport (with maybe some quirks at SCSI command level > tho, IIRC). ATA is neither thansport nor does it map to SCSI 1:1. Well, to be wholly accurate, since SCSI-3, SCSI has been separated into an architecture, primary command, device specific command and transport model (called the SCSI architecture model). Starting with ATA-8, ATA will go this way again. What ATAPI actually is is a SCSI (really MMC for CD and SSC for tape) command transported over ATA using the ATA PACKET command. With ATA-8 it will be much more analogous to SCSI command over ATA transport. > The > code for emulating SCSI on ATA only burdens the kernel (and causes user > complaints about changing disk names from /dev/hdx to /dev/sda :-). The code for sorting this out is already upstream in the block tree for 2.6.29. > > I'm actually seeing two strands of requests (including from embedded) > > > > - CF only small "dumb as president" type driver that is written to be as > > compact as possible and preferably considers IRQs as optional > > > > Yes, support for IRQ-less CF is what IDE core lacks. I must note > however that IRQ-less mode looks inherently risky to me because of the > raciness of tbothe the ATA spec and its implimentatin WRT the "interrupt > pending" state. I may be mistaking but someone of T13 experts (Hale > Landis I guess) told me that the devices require that state to be > cleared to proceed with the command, and that's what the fast polling > host is likely to fail at because it doesn't know if rthe device has > actually entered this state when BSY is cleared... Oh well, that's an > old story... > > > - Full SATA and NCQ aware platform support. > > > > I don't see how SATA/NCQ support is connected to SCSI. They require features that SCSI has had for a long time for TCQ but which weren't present in block. Originally I'd been promised that libata would be out of SCSI within a year (that was when it went in). The slight problem is that having all the features it needed, SCSI became a very comfortable host. Getting libata out of SCSI was also made difficult by the fact that few people cared enough to help. The only significant external problem is the size of the stack and the slight performance penalty for SATA disks going over SAT. Unfortunately for the latter, slight turns out to be pretty unmeasurable, so the only hope became people who cared about footprint ... and there don't seem to be any of those. The other problem is that it isn't just moving libata out of SCSI. To do this correctly, SCSI itself needs to be sliced up because lots of devices running over ATA transports are genuinely governed by SCSI protocols (CD with MMC and tape with SSC), so we have to be able to run sr and st over an ATA transport, thus it needs the minimal pieces of SCSI to function. This in turn necessitates splitting the whole of the SCSI mid layer into a stand alone upper layer support library and a lower layer platform, which is a significant piece of work. The way it's happening is that people keep thinking of incremental steps towards this (ULD separated from SCSI, block timers, sd device allocation separation, block error handling) and doing them, but lacking a major spur, it's going slowly. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
