On Tue, Feb 18, 2003, David Brownell <[EMAIL PROTECTED]> wrote: > >>Seems like a UHCI-specific expectation, so it's UHCI that should > >>be adding the extra reference count. (Rather than breaking the > >>other HCDs, which just rely on the URB having a valid device ptr.) > > > > If they make that assumption too, then they should be using reference > > counting too. > > They don't make that assumption (don't reference devices that way), > so they don't need to. So that change should be UHCI-specific.
You said that they rely on having a valid device pointer. They must do reference counting then. Or by valid do you mean a properly counted reference or a NULL pointer? > >>>I don't think setting dev->bus to NULL is the right way, simply because > >>>the bandwidth is not available to the rest of the system until all of > >>>the URBs have been fully removed. To handle the bandwidth correctly, we > >>>need that pointer to the end. > >> > >>I think it's the best way in the current system to flag a device that's > >>gone. The whole of usbcore already checks for null pointers, and it's > >>a classic solution. DEVICE_GONE in <linux/device.h> enum device_state > >>doesn't seem to help, and needs a more solid backup anyway. > > > > But with reference counting, NULL pointers aren't really needed. Just > > keep the proper reference count. > > It's not "just" that ... but if it were, then surely having those > unusable pointers become null could not matter, right? Since no > non-erroneous code would ever be using them. :) If you don't use the pointer anymore, then you can release the reference to it and change it to NULL, yes. > > I'm really surprised that usb-ohci.c still gets this wrong in 2.4, even > > after our "discussion" months ago. > > Considering that discussion was about 2.5, I'm not at all surprised that > the 2.4 code didn't change. (Except for the historical digression, where > I pointed out that the original bus->op->deallocate logic, in 2.2.early, > was designed to work exactly as I described; so the bug crept in later.) 2.4 works the same way, which means that's it broken. In fact, I traced down a problem I had recently with usb-ohci.c under 2.4 recently to the poor assumptions it makes about the reference counting. That's the patch I was referring to. > What surprises me is that you have such strong opinions about methods > that your UHCI code doesn't use, and have been so "reluctant" to recognize > the problems which came from the approach you've pushed. You make it sound like I solely advocate reference counting. I suggest you look at the rest of the code in the kernel. I'm just trying to get the USB code to work the same way because it works well and makes sense. Having code block on releasing resources is dumb when reference counting handles it a simpler way and correctly too. JE ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
