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.gerryg400 wrote: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.
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?