> > The old drivers contain a fair amount of crap, magic and gueswork so a > > good deal of human analysis and testing is needed to move any change > > around and prove it's real and valid not guesswork and fudging. > > And then once that hard work is done, we kind of just toss it > for one side of the equation? I don't where you got that idea from. The "merge" makes it harder to maintain both, adds lots of ifdefs and artificial divisions of code stuffed into include files. Its ugly as sin and makes *both* sets of drivers harder to maintain. So it's quite clearly cheaper and more efficient to propogate any relevant fixes both directions than produce a single ifdef and include filled turdpile that can't be maintained at all. It's not as if either set of drivers change on a regular basis. Plus I'd point out the calling patterns, locking and the assumptions of the two stacks are not quite the same. There are also things the old stack can't do (eg hotplug, queued commands, intelligent serializing of command sequences) or that the current stack can't do (generally because they make no sense moving forward but also stuff like user issued SETXFER snooping) Alan -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
