ATA/BlockDevice adapter

[RaffoPazzo]

I'm very confused by this approach. Why would a function like "isDmaSupported" need to be exported ? Surely only the driver itself needs to know whether DMA is supported.

And the difference between readSectorChs and readSectorLba would surely be buried within the driver and the exported function would be simply a generic readSector.

The approach is based on a simple idea: map whatever a specifcation/standard/interface declares. The ATA specification declares that an ATA device can support DMA. This optionality suggested me that a getter method would be useful, i.e. to inquiry the device if it is capable or not of such operations. Why a client should be interested in this kind of inquiries is a matter of the client itself.

A generic readSector would not bury the difference of reading a sector by addressing it by CHS or LBA, just because there is a difference in the way you address the sector. It is an existential matter. The closest thing you talking about would be overloading a readSector method (like in C++ or Java one would do) but this is just accidental, there will always be two methods because of there are two ways to address a sector, no way out. In this scenario, isLbaSupported would be used (and it actually has been used) by a client to switch over the method to call. A client cannot ask to read a sector addressing it by its LBA, if the underlying device is not supporting LBA.

Back to the topic, have you got opinion about which package should be responisble for containing an Adapter? Alternatively, would you agree with NickJohnson to let the hw_generic_ata_Ata interface extending kernel_io_block_BlockDevice? Or even have you got thirds ideas?

[Kevin]

Why should I as a file system (or even application) care about the idiosyncrasies of some specific device? The only thing that makes sense for a block driver interface that a file system accesses is using linear addresses, and probably even in bytes, not in blocks. Anything that deals with strange things like CHS is part of a specific driver.

Of course you are free to decide what this driver looks like. You may choose to implement the real driver as a library that provides everything the spec contains, and then use a small wrapper implementation to map it to your block driver interface. It's probably a waste of time to implement functions in your library that you're not going to use anyway, but you can definitely do it. However, in this case it's an implementation detail of the specific driver and not something that influences the design of your OS in any way.

[Brendan]

Hi,

Why should I as a file system (or even application) care about the idiosyncrasies of some specific device? The only thing that makes sense for a block driver interface that a file system accesses is using linear addresses, and probably even in bytes, not in blocks. Anything that deals with strange things like CHS is part of a specific driver.

I'd assume the OP is trying to have driver/s for ATA controllers and separate drivers for devices (hard disks and CD-ROMs) that are attached to the ATA controller. File systems would use linear addresses to talk to hard disk and CD-ROM drivers; but hard disk and CD-ROM drivers would use a lower level interface to talk to the ATA controller driver - something that supports CHS, LBA, LBA48, ATAPI, different PIO modes, different DMA/UDMA modes, etc.

In this case, I'd probably have a "do_command()" interface where the driver for the ATA controller knows nothing about the commands themselves, and only knows how to send commands, how to obtain/return any status returned by commands, and how to transfer blocks of data to/from the devices. Rather than providing functions like "identify()" and "read_sectors()" the the ATA controller driver would provide a generic function like "int do_command(struct args_for_command, struct args_for_setting_up_transfers)" that a hard disk driver or CD-ROM driver can use for a wide variety of different purposes (including "identify", reading sectors, etc).


Cheers,

Brendan