Hi,
...
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.
They never make a copy of urb->dev ... so they relying on drivers to
have provided a valid device pointer in the first place. As they must;
if they didn't, nothing would ever work!
If you don't use the pointer anymore, then you can release the reference
to it and change it to NULL, yes.
And in fact if you release the reference count, you SHOULD null that
copy of the pointer.
Because otherwise, there's a non-refcounted copy of the pointer sitting
around, that someone will likely end up using at the worst moment ... :)
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.
I haven't seen it. I wouldn't rule out hcd bugs, but as a rule the
refcounting problems I've seen have always been in device drivers:
some URB still in flight when disconnect() returns, or submitted
after that. (Greg's patch prevented the latter.)
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.
There's lots of code working lots of ways ... :)
In particular, there are different policies for different kinds of
resources. Chunks of memory can reasonably be refcounted in many
cases. But breaking a linkage between two components tends to use
more of a handshaking protocol, and to involve process contexts.
Dare I mention module unloading, as something that uses both a
refcounting scheme (for the wrong things still, but that's for a
different thread!) and an explict handshake? It might come a
bit too close to being on-topic though!
Having code block on releasing resources is dumb when reference counting
handles it a simpler way and correctly too.
I can't think of this case as just a memory management issue.
It's in that "break this linkage" territory. The method in
question has also _always_ been misnamed, and didn't reflect
how it got used from day one: not memory, but linkage.
Certainly when I program in some OO language (C++, Java, whatever)
I know that one of the options is to make destructors try to break
linkages. But that approach tends to be problematic, so larger
systems I've worked on usually end up not using it all that much.
- Dave
JE
-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
