OSDev.org

Hey guys, I am playing with the xv6 kernel and want to improve its IDE disk driver. The xv6 doc said ''Modern disk controllers typically accept a batch of disk requests at a time", and that is my goal. But as far as I know, IDE driver uses in/out instructions to communicate with disk, as the following code shows:

Based on above knowledge, I don't know how to implement an IDE driver that can issue a batch of requests(e.g., read block 3, read block 5) to disk all at once. Maybe I can use a loop to wrap all outbs in above code? I want someone to point me to the right direction, thanks.

I'm not sure if xv6 already uses PCI DMA for the ATA driver, but if it doesn't, look into it. You can serve batches of requests by just adding another entry to the PRDTs.

You can't, the PRDT only lets you use a scatter/gather list for a single request. IDE just isn't a modern disk controller interface and allows only a single request at a time. If you want more than that, AHCI can do parallel read/writes with the NCQ commands.

Are you asking about something similar to a disk-block queue? That's what I do. (and I believe xv6 does as well)

I just add requests to a queue and then the driver responds to each request on the queue whenever an interrupt is triggered

Part of the problem here is that the statement - and hence the answer - is ambiguous. What constitutes a 'modern disk controller'? IDE probably doesn't count; it is a legacy standard from the late 1980s and early 1990s. Most likely, the author was talking about controllers that implement AHCI (the implementation-independent ABI developed for the SATA physical interface standard), as Kevin said.

All compliant SATA drives should support an AHCI mode, but they usually will also emulate PATA (the retroactively-applied term for IDE and other related parallel interfaces) for legacy operating systems, and some will have an implementation-specific mode as well which exploits the specific hardware better than AHCI can. While the ideal would be to have a driver for as many of the individual drive models as possible, most low-end manufacturers don't bother to do more than AHCI does, and even for those who do, there are far too many for even Microsoft to support themselves. Even if you want to write a driver for a specific high-performance drive, the interface is probably proprietary, meaning that unless you get a driver from the manufacturer themselves you need to just use AHCI.

Sorry, I should have finished that but I had to go take care of something quick.

Anyway, the first question becomes, is it actually an IDE drive, or a later-model EIDE, PATA, SATA (or even SCSI, depending on the age of the drive and the controller) drive that is emulating IDE for backwards compatibility? Most true IDE and EIDE drives have long since succumbed to stiction (of which the infamous "click o' death" is the first symptom), so chances are it is a SATA drive masquerading as IDE. The drive device info in either Windows or Linux should be able to tell you, and if not, and you can open up the case, you should be able to tell just by looking at the physical connectors (the PATA style connectors are broad and narrow, about 2"/5 cm wide but about a 0.25"/6 mm thick), and usually used a ribbon cable, while the SATA connectors are about 0.4" /1 cm wide and 0.125" / 3 mm thick and use a thinner, singly clad cable).

Thank you all. So the hardware, disk controller, must have a command to support receiving a batch of requests, or nothing I can do. And it seems like the old IDE(PATA) disk doesn't support this feature.

Do you know the make and model of the drive, and the year it was manufactured? According to Wikipedia, the ATA-4 standard has a 'tagged queued operations' mode, meaning that PATA drives which are from 2002 or later will generally support it. As I said earlier, most drives that old or older won't even be functional anymore due to stiction - while drives made after the mid-1990s are a lot less prone to it and would run for several years longer than earlier drives, is still happens to most HDDs eventually IIUC.

You're jumping to conclusions. That a standard contains some optional feature doesn't mean that it gets implemented by actual hardware. If you'd read a sentence or two further in the same article: "However, support for these is extremely rare in actual parallel ATA products and device drivers because these feature sets were implemented in such a way as to maintain software compatibility with its heritage as originally an extension of the ISA bus. This implementation resulted in excessive CPU utilization which largely negated the advantages of command queuing."

OK, I didn't read that part. I don't know why I am being so careless about things like that lately. Sorry about that.