Am Montag, 14. Oktober 2002 18:11 schrieb David Brownell:
> >>And they might not time out, depending on how they're called.
> >
> > What causes this ?
>
> Caller didn't ask for a timeout. ;)
This has to be fixed.
> >>>>>Races with probe:
> >>>>>usb_reset_device, a probe while resetting is bound to malfunction
> >>>>
> >>>>Like David said, I don't think this is a problem.
> >>>
> >>>Then usb_reset_device() should be removed from usbcore and added
> >>>to the storage driver.
> >>
> >>It can't be added to storage ... enumeration tweaks internal
> >>usbcore state that shouldn't be generally available.
> >
> > Then it has to have proper locking, basically neither probe()
> > nor disconnect() must run concurrently to usb_reset_device()
> > and no other synchronous helper should run.
>
> That seems right to me. I'll be glad if that whole mess of
> device state management starts to get more sensible.
>
> It might be worth adding a field to the usb device struct,
> an enum with the various device states, and maintaining it.
> At least while debugging, some BUG_ON(state!=CONFIGURED)
> statements might help shake loose some of the less obvious
> issues. (Where the locking stuff you're working on has
> previously been in the "obviously broken" state!)
Had I only known. The more I think about it, the harder it gets.
The problem again is that it needs support from the drivers as well.
The problem is that disconnect() frees the memory.
Regards
Oliver
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
