On Tuesday 05 February 2002 02:25, David Brownell wrote:
> With respect to new API entries to distinguish the synchronous
>
> and unsynchronous unlink cases:
> > An asynchronous unlink due to being asynchronous allows other
> > things to happen while it is underway.
>
> Same thing for a synchronous unlink -- except the initiating
> thread can't cause them, it'll be blocking till the unlink is done.
Yes, exactly.
> > Therefore the need to do
> > a synchronous unlink while an asynchronous unlink is happening
> > may arise.
>
> I think I see what you're suggesting, but I'd basically say what I've
> said before: drivers which are that confused about how they work
> are really asking for trouble! APIs that try to work with code that
> broken have a nasty problem: they foster even more broken code.
They need not be confused. They are usually forced by external
circumstances, especially the network drivers.
All USB drivers need to unlink synchronously at least in disconnect.
So if you are forced to unlink asynchronously (perhaps by being
called with a spinlock held) you have to do both.
The only question is now whether the API allows you to do it easily,
or whether you have to use the asynchronous method of the API
and do the waiting yourself.
> For example, only one "it's unlinked!" callback will ever be seen,
> but if both synchronous and asynchronous unlinks of the same
> URB are both expected to succeed, it's unclear what urb->status
> should be used: -ECONNRESET or -ENOENT.
>
> (Frankly I think that there should only be one urb->status code
> for the unlink completion. The calling thread clearly knows which
> mode it's using, and that's sufficient.)
You could in theory call the completion handler twice,
but your suggestion of using a common error code is
excellent.
> > This would be vastly simnplified and could be pushed into the hcd layer
> > if the functions had seperate names.
>
> Still doesn't _require_ separate entry points for sync and async
> unlink.
Well how do you initiate a synchronous unlink while an asynchronous
unlink is running ? You scarcely could mess with the transfer_flags.
> While there are some changes I'd like to see in the link/unlink
> behavior, they're more at the level of new flags saying whether
> the URB is linked to the hardware, and whether unlink has been
> requested. It's nasty to encode unlink state in urb->status, where
> it will sometimes obliterate _real_ transfer status.
Does this have to be visible to the drivers ?
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
