Bartlomiej Zolnierkiewicz wrote:
I've started reading it and immediately noticed a thing which made by day. :-) Sorry if it will sound off-topic or undiplomatic but it is the best occasion to straighten up some facts: "Discussion then moved on to the current status of getting libata out of SCSI: we have had several successes, notably timer handling and pieces of error handling have moved up to block. Unfortunately, the current progress has reached the point where it's being impeded by the legacy IDE subsystem Heh, you can also blame the lack of world peace on the legacy IDE subsystem. I wonder who came up with this ridiculous excuse (I'm sure it wasn't James!). The thing is that during last _five_ years almost nothing was done in this direction. Despite the fact that it was #1 condition under which the whole code has been merged. Sorry to say it but it seems like the whole merge strategy was to over-promise things now and worry about delivery later.
Yet, shockingly, users have been happily using libata despite all these horrors.
To make things worse all the "successes" quoted above are nothing else like back-ridding on block layer and SCSI improvements which were done by non-libata developers.
False. Tejun authored many of the changesets getting timer and error handling "moved up the stack."
which is still relying on some very old fields and undocumented behavior of the block layer, since the next step is to simplify the block to low level When it comes to block layer interactions the legacy IDE subsystem is just another "dumb" (== very simple) block layer driver.
Hardly. The IDE driver has all sorts of special cases that no other block driver has. One must roll dice to see which of rq->special, ->buffer, ->data and ->sense is filled in, and at what times. Is ->buffer, ->data, etc. pointing to a buffer... or an opaque kernel data structure? None of this is clear or documented.
REQ_TYPE_ATA_* is still around. Overall the consistency of request handling across the IDE class drivers is low. ide-tape sticks out like a sore thumb with its use of current_nr_sectors.
IDE's interactions with the block layer are quite complex and opaque, compared to other block drivers.
Jeff -- 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
