> > > 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.) > > > > Hm, we should probably fix that. We should test for that in the usb > > core before passing the call down to the host controller driver.
Simple fix: don't merge Johannes' changes. > That's a device driver bug. If it's still hanging onto references and > the module is removed, it's a bug. > > That has nothing to do with the core, or HCD's. Johannes, your arguments have boiled down to not wanting the core to detect or prevent such oopses. I really don't understand why, since the cost to correctly written device drivers is zero and the _value_ of detecting/preventing such problems is significantly higher. (Measurable in years that such bugs have otherwise been creating random problems before someone finally figures out what's wrong. Consider cases like "printer" and "usbfs".) > > So should we add a BUG() call if_interrupt() is true when we go to > > clean up the finally usb_free_dev() call to catch for this? Again, simple fix: don't merge Johannes' changes. > NO, NO, NO. usb_free_dev() is called when the last reference is > decremented, which can be in ANY context! > > But it doesn't matter since usb_free_dev doesn't do any blocking. The HCD is most _certainly_ allowed to block when cleaning up device state. Every device management API I've had reason to look at in Linux guarantees that the the "clean up after this device" call can block. I don't care at all about the memory management, except that as I said elsewhere, I can't see any case where the device memory should reasonably be kept around after the cleanup call is made. > > > 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. > > > > If we add the BUG() mentioned above, how are things more fragile? > > Personally, they look more stable to me. Today (2.5.15) the BUG() test is being made. That's how I can say that they're not going to trigger such bugs, and how overall stability is better today. And the ONLY lack of stability is for folk using "uhci.c" ... or for new drivers that haven't gotten rid of disconnect() bugs yet. Which IMO is a good sign, particularly since the updates to "uhci.c" are so simple, and since the new device drivers will get nice clean BUG() reports if they screw up. > Just code the drivers correctly. > > The kernel is not the place to coddle coders who cannot code correctly. > It's a dangerous place and it'll remain so for a long time. Likewise, the kernel is not the place to design-in fragility for the component interconnections. (Fragility like hiding errors.) It's a place where good coding discipline -- like defining and preserving invariants of all kinds, like the BUG() tests you object to -- is well rewarded in terms of system stability. - 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
