Hi Pete,
> > What's so bad about freeing inside a callback? When else
> > would most drivers have all the facts in hand, so they know
> > that they're done using a given URB? Inquiring minds ...
>
> Short answer is "too confusing". I am sure Dan did a due dilligence
> looking at code paths and yet he blew it (I would too...).
That's one reason I've wanted to see the URB lifecycle become
more carefully specified. In this case, the rule is easy: once the
HCD returns the URB to the device driver, it may _never_ touch
that URB again. I see nothing confusing about that; simple rule,
simple consequence.
Now a HCD, on the other hand, is a fundamentally confusing
sort of beast. That'd be true even if there were the degree of
consistency between HCDs (ohci, uhci*2, ehci) that I believe
should exist (but doesn't); they're just complex chunks of code.
I doubt that anyone who's really wrapped their heads around
(and inside :) one will disagree.
> I know where the desire to free inside comes from, we want
> to reuse URBs. This is fine, but in that case let's always
> free them inside.
That's a device-driver policy. Some allocate URBs statically.
That ought to be fine -- for those drivers. Likewise, it should
be fine for other drivers to dynamically allocate/free URBs.
> I saw how Dan proposes freeing from a BH. That would be
> wasteful, I think.
I don't know about "wasteful", but certainly confusing.
The question to answer is: at what point does the HCD really
give up all ties to the URB, if it's not the completion function?
Creating additional points in the URB lifecycle makes the
HCD/usbcore framework more complex -- which is in
my book a very bad thing, it's too complex as it is.
Complexity there means more bug possibilities.
> What next, a tasklet? We saw that too :)
> [I am talking about Mr. Ananian's exercises]
Well, an architecture-specific memory management quirk
deserves an archtiecture-specific fix ... :)
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
