Naturally I don't like this patch, and I may comment more on it a bit later when I'm not just up late and sleepless ... :)
But I'll correct a few misstatements right now about the current 2.5 behavior. (And for what it's worth, only "uhci.c" has any problems with that -- from what I've seen.) > - It made the USB code more complicated as a whole with the introduction > of an additional cleanup path for devices. Not so. It has detected/reported failures to correctly support the _original_ cleanup paths, though. For example, device drivers that hang on to references after their disconnect() methods complete. (Which can make "rmmod" break, for example completion callbacks going to where the module used to be loaded.) And it's guaranteed that the *hci_free_dev() code is called in a thread context, per the original API guarantees. And also matching the behavior of every other Linux device driver framework I've had a chance to look at. One thing to keep in mind is that to the extent that many device drivers _today_ are working "correctly", they're not going to trigger such bugs. However, Johannes' change makes the kernel more fragile in the face of newer drivers which do have bugs in such areas. > The change in 2.5 also only helps catch one subset of programming > problem in device drivers, the case where it decrements too many times. Actually there's the "too many times" case, and the "not enough times" case. Driver disconnect() bugs have triggered both ... and now they're clean/consistent errors, rather than random flakiness. And it _prevents_ the thread context botches too, which I know that Johannes doesn't care about because "uhci.c" doesn't use those routines. (Is the argument that it's not good to catch two or three categories of driver bugs, then?) > This patch doesn't remove all of the superfluous code. Some drivers, > like usb-ohci, ohci-hcd and ehci-hcd have some code that is no longer > needed. Not true -- you're changing the core to be friendly to "uhci.c" without having looked enough at those other drivers. For one thing, you have guaranteed that several of those drivers will break rudely in the case of certain device driver bugs ... by changing the semantics of the *hci_free_dev calls to remove the original "called only in thread context" guarantee. - Dave _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
