> > > > > 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.) > ... > > No, I think this should be allowed.
Surely you didn't mean rmmod oopses? I think you're saying that you're OK with some kind of new "zombie" device state in such cases, but not the behavior found in Johannes' patch (which allows oopses by calling into recycled memory). > > 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".) > > printer and usbfs has not had usb_dev problems in the past, right? On the contrary, they absolutely have had such problems. In the very recent past too -- that's why I mentioned them. I think the fixes are in the 2.4.19 prepatches. > > 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. > > Ok, a BUG() call if in_interrupt() is ok with you? Not really, since those avoidable BUG() calls would be appearing at non-reproducible times. That's a clear step backwards. I just proposed an even simpler solution, moving the call to dev->bus->op->deallocate(dev) call out of the memory management path entirely, and put it at the end of the usb_disconnect() code. (Which is where it's now firing for everything except "uhci", which isn't happy with 2.5.15.) Then there'd be no BUG() checks at all, and the only substantive change of Johannes' patch is to formalize (partially :) this new "zombie device" state so that "uhci.c" can provide/use it. (Or so that buggy device drivers can leave devices in that state.) - 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
