A different ATA driver [LWN.net]

Much work has been done through 2.5 to improve the ATA/IDE layer. The work of Bartlomiej Zolnierkiewicz, Alan Cox, and others has brought a great deal of order and correctness to this code. Not everything that might have been hoped for at the beginning of 2.5 has been done, but things have clearly moved in the right direction.

Meanwhile, Jeff Garzik has been quietly developing a completely different driver for ATA drives; he posted libata 0.70 this week. Jeff's driver concentrates on newer hardware, with an emphasis on serial ATA drives. The interesting aspect of libata, however, is the approach it takes: it essentially functions as a translation layer which makes ATA drives appear to be SCSI devices. They are managed by the SCSI layer, and do not appear as IDE drives to the user at all.

This is not as strange a thing to do as one might think. The ATA protocol is heavily influenced by SCSI, so many SCSI commands can be passed through with little processing. But the real advantage of this approach seems to be that it can take advantage of the existing SCSI mid-layer. The SCSI code takes care of a lot of the work, and already supports a number of needed features (such as hotplugging). For a developer who wants to make a new, "legacy free" driver for modern ATA hardware, plugging into the SCSI layer offers a lot of advantages. This is especially true for serial ATA, which presents a lot of SCSI-like handling issues.

libata is not intended to replace the current IDE layer; it makes no attempt to handle the wide range of hardware that the IDE code copes with. It could be, however, the driver that many of us end up using in a couple years or so. Sometimes you have to leave the old stuff behind and look to the future.

to post comments

ATA vs ATAPI vs IDE

Posted Aug 14, 2003 17:23 UTC (Thu) by pflugstad (subscriber, #224) [Link] (2 responses)

Can someone post a link to a doc somewhere that explains the differences between all these interfaces. I know I've seen comments and such that indicate that ATA != ATAPI, and that IDE != ATA, but I've never seen any thing that explains the various differences. Google doesn't appear to provide much, all I find is comparisons between SCSI and ATA. Thanks.

ATA vs ATAPI vs IDE

Posted Aug 14, 2003 18:42 UTC (Thu) by remijnj (guest, #5838) [Link] (1 responses)

As far as i understand it, IDE == ATA and ATAPI is scsi commands (command packets) over ATA. For a larger IDE/ATA explanation see:

http://www.pcguide.com/ref/hdd/if/ide/

Joost

ATA vs ATAPI vs IDE

Posted Aug 15, 2003 0:58 UTC (Fri) by giraffedata (guest, #1954) [Link]

That link gives a great explanation. For those not interested enough to read it all, I'd like to emphasize the most important part:

IDE is a very widely used misnomer for ATA. IDE is a technology in which a disk controller is packaged with the disks and heads. All modern disk drives, including SCSI, are IDE. ATA is a disk drive interface standard. But before the advent of SCSI, all IDE drives were ATA, so people accidentally picked up on the wrong name.

Indeed, the Linux module ide.o should have been named ata.o.

SCSI over everything and everything over SCSI

Posted Aug 15, 2003 3:23 UTC (Fri) by bgilbert (subscriber, #4738) [Link] (2 responses)

Isn't this getting a little ridiculous? ATAPI CD burners already pretend to be SCSI devices (under 2.4, anyway). USB Storage-class devices pretend to be SCSI devices. The drivers of some ATA RAID cards present their arrays as SCSI disks. I seem to recall that awhile ago there was talk of generalizing the SCSI midlayer, so that other block drivers could use the useful bits without pretending to be SCSI devices. Maybe it's time that this work gets done, before someone starts porting the RAM-disk drivers to the SCSI midlayer?

SCSI over everything and everything over SCSI

Posted Aug 15, 2003 3:58 UTC (Fri) by cpeterso (guest, #305) [Link] (1 responses)

I agree that the Linux SCSI code is being overloaded. Whatever is so great or useful with Linux's SCSI module should be refactored and abstracted into a more general I/O module, which is shared by SCSI, ATA, etc. These layers on above or beneath the SCSI code is just the type of extra layers of cruft that I thought Linux kernel developers wanted to jettison.

SCSI over everything and everything over SCSI

Posted Aug 23, 2003 20:29 UTC (Sat) by rrw (guest, #9757) [Link]

You obviously observed the facts but came to wrong conclusions. Those drivers (atapi, usb-storage, and IIRC firewire-storage) don't pretend to be SCSI. They _are_ SCSI over different medium. They send the same commands, they accept the same replies, their data is the same. The only thing that differs is that those commands and data come from ata or usb bus, or in case of iSCSI from the network.

Implementing all scsi properties into block device api would be very bad idea since:

1. not all scsi devices are block devices by their nature
2. not all block devices need the overhead of scsi implementation

Robert