I was just chilling down late in the evening by reading a short LKML overview, and then inadvertently managed to hit this bomb shell ;) > As uas has not been in a release-kernel, by definition, there is no > impact either way. No regressions or anything else. Since I've actually just been oldconfig'ing uas driver yesterday on a new installation, I can relate to UAS kernel support being quite new in its entirety. If this is the case, then I'd also tend to believe the situation is very different from other more painful (since longstanding) driver conflicts (e.g. 8139, some raid drivers, and also e100 as witnessed by myself). The author of UASP might want to adjust some of his writings (especially the more personal parts), however several parts of his criticism (e.g. no focus on code review) seem valid from my POV. If the new driver indeed is a whole lot better than the other newly submitted/unreleased driver, then I'd fully welcome a reevaluation of the situation. For the author of the original submission this might of course be a "less than positive" (to put it extreemely mildly) situation. Still, I'd hope that there could be sufficient agreement on how to proceed and how to make sure to have the most fitting code get into the kernel and be maintained properly, ideally by continued interest by _both_ authors (or perhaps via "personality firewalls" ;), obviously. Alas, I'm feeling like I'm stating obvious blathering here. Anyway, by now you know which direction I'm tending in, despite the not terribly warm writings by a certain author ;) Disclaimer: no code review (comparison) performed, sorry. Disclaimer #2: as the author of a still-outstanding kernel patch (uhm - hi Greg ;) I'm in a sufficiently unfavourable position to comment on this... Andreas Mohr -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
