Hello, Bartlomiej. 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!). Eh... It was my session. It probably is a bit too summarized. I wans't really trying to blame IDE. The point was that, at this point, adding any feature to the block layer is pretty precarious because in many places block layer API has become somewhat ambiguous and many users have been abusing in interesting ways for quite some time. IDE, due to its history and complexity, happens to be the most complex one to clean up, so that was why IDE was mentioned in the session. It's not like IDE has been preventing libata separation for all those years. It's more like, when finally I got my lazy ass moving about moving features from SCSI midlayer to block layer, I realized I better clean up block API before moving forward and IDE was the most difficult user of block API in the process. I apologize if it sounded like an attack on IDE. It's true that IDE is the biggest block API abuser but it's mostly due to its long history and inherent complexity and you have been doing a lot to clean it up, so let's get it done. I just came back and am still recovering from time difference. As the block map thing kind of became unnecessary, I'll soon test IDE tape support and repost them. Thanks. -- tejun -- 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
