hrm.. I know I shouldn't jump in to something like this late, but...

I'm starting to agree with Alan Cox.  The problem with Oliver's suggestion
below (keep a reference to a submitted URB) is that I still don't know when
it's safe to free such a beast.

If we say that an URB is referenced by both the HCD and driver, the driver
can free the URB when the HCD no longer references the URB.  When is that?
It is clearly not during the completion handler.  So it's after the
completion handler returns.  How long after?  How do we tell when enough
time has gone by?

The refcounting problem would solve all that, especially if the "decrement
count" function does an automatic free when the count hits zero.  Yes, it
means that you need to manage the refcounts.  But is that such a problem?
If nothing else, doing explicitly will clear up the ambiguities.

You could decrement the refcount anytime, even in the completion handler.
If you do it in the compltion handler, then when the HCD is done with the
URB, it automatically goes away.  If the driver does it after the completion
handler (and it doesn't matter when), then the URB will get freed then.

If, on the other hand, the HCD really is done with an URB when it calls the
completion handler, then there is no problem.  The completion handler can
free it (making sure to inform all other parts of the driver that the
pointer is no longer valid), or the driver can free the URB later.

Notice that, however, the refcounting solution works in all cases.  So if a
new HCD came along which couldn't (for whatever reason) release the URB
before calling the callback, we would still be okay.

Matt

On Wed, Jan 16, 2002 at 01:17:59AM +0100, Oliver Neukum wrote:
> On Wednesday 16 January 2002 00:15, David Brownell wrote:
> > > There are hundreds of drivers, and three hcds. Surely it would be better
> > > to let the HCD do the relevant hoop jumping in these cases.
> >
> > They do.  Apart from some massive (and it "really serioiusly"
> > appears to me, intentional) confusion on Oliver's part, I don't
> > see a problem.
> 
> No, the real simple solution here would be to state that an urb that has
> been passed to a completion handler is referenced and must not be freed,
> not even by the complition handler itself.
> In the literal sense there are two references to that urb.
> One is held by the complition handler/usbcore and the second is held by the 
> driver. The driver must retain a reference to an urb it has submitted, because
> it needs a reference to unlink it.
> 
>       Regards
>               Oliver
> 
> _______________________________________________
> [EMAIL PROTECTED]
> To unsubscribe, use the last form field at:
> https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

-- 
Matthew Dharm                              Home: [EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

Your lips are twitching.  You're playing Quake aren't you.
                                        -- Stef to Greg
User Friendly, 8/11/1998

Attachment: msg04004/pgp00000.pgp
Description: PGP signature

Reply via email to