In message: <200902190926.42992.hsela...@c2i.net>
Hans Petter Selasky <hsela...@c2i.net> writes:
: Do you understand why probe and attach is currently partially deferred in
some
: drivers? It has to do with the ability to quickly recover if a device is
: suddenly detached when doing multiple sequential USB operations towards a USB
: device. I have the impression that you are not thinking about failure cases
: like constant timeouts. What makes the picture additionaly complicated is
: that there are multiple sources of detach, that do not all go through the USB
: stack.
:
: kldunload does not go through the USB stack.
: set_config does.
: device_detach does.
You are doing something wrong then. All of these *DO* go through
newbus for proper drivers. If not, then that's a bug in newbus and
should be fixed there, not kludged around.
What, exactly, is the problem with kldunload?
: Another point I have is that we want to do operations in parallell. I see no
: reason at all to slow down the USB enumeration at boot. We are talking about
: a considerable amount of time! Instead the system needs to be changed. If you
: try to mount a device which is not present, then you need to retry mounting
: that device if some re-try flag is set.
None of this prevents the usb stack from signaling when the
probe/attach is done. You can't expect mountroot to wait forever.
Also, there are times when there's multiple disks available that could
be root. Just waiting for root is also bad because that root might
not ever get there. There has to be some sanity timeout. By properly
signaling that the operation is complete, you can have better
semantics. All the other drivers in the system can accommodate this
paradigm. What makes usb so special?
: Adding some flag to "struct usb2_device" saying that the device is gone will
: almost solve the problem, but it does not cover the kldunload case. Also it
: can be quite dangerous if attach is hanging and we do a kldunload. Then I
: don't know what will happen. And we don't want to open that window by making
: USB attach always synchronous. Neither should we depend on the EHCI/OHCI/UHCI
: hardware to simply eject transfers on dissappeared devices, see three strikes
: and you are gone rule.
These sound like they might be bugs in newbus. Can you elaborate on
the details?
Warner
_______________________________________________
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
