On Tuesday 14 April 2009 05:30:42 Tejun Heo wrote: > 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. Right, this is the proper way of doing it. > 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. No worries, lets focus on cleaning this up. Thanks, Bart -- 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
