Am Sonntag, 11. Juli 2004 05:08 schrieb David Brownell:
> Oliver Neukum wrote:
>
> > That tells us the there is a multitude of operations that need locking.
> > Not that these operations are common. Maybe except usbfs. Wouldn't
> > usbfs be happy with down_read()?
>
> The issue was whether providing one "global" mutex could do the
> whole job, I thought.
>
> Consider: one userspace program would be able to issue a read
> (or write) on an endpoint that's NAKing. That can take weeks to
> complete. It would then make khubd wait for weeks (*) ... to
> notice that you plugged in a keyboard to help kill that read!
>
> Loosen that to a single global rwsem. Now one problem is that
> it would take those weeks before some other application could
> register+use a new driver module (not a usbfs issue). Hmm ... (**)
These are important issues. But I don't think that you can avoid them
entirely if you need a multidevice form of locking.
As you cannot reset a hub without its children, anybody holding a lock
could prevent it. By finer graining of locking you can certainly decrease
likelihood, but you cannot prevent it. It seems to me that unbounded
waiting with a common lock held is a bug. So it seems to me that this
is sort of jumping to conclusions.
Regards
Oliver
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
