> > 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".) > > Nope. That's not how the kernel works. We optimize for ease of coding, > maintainence and understanding.
One aspect of "ease of maintenance" is ease of isolating/fixing bugs. It's always easy to write buggy code ... and making it easier to write _correct_ code is a different goal than making it easier to just write code. > > > 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. > > You haven't been looking hard enough. Take a look at all of the > networking code. You mean like unregister_netdev()? Which is guaranteed to call net->stop() in a thread context? Sorry, I know that one. - 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
