14 messages in org.freebsd.freebsd-hackersusbd config file parse behaviour| From | Sent On | Attachments |
|---|---|---|
| Sam Lawrance | Mar 25, 2004 3:26 pm | |
| Bernd Walter | Mar 25, 2004 11:49 pm | |
| M. Warner Losh | Mar 27, 2004 3:56 pm | |
| Bernd Walter | Mar 27, 2004 4:25 pm | |
| M. Warner Losh | Mar 28, 2004 12:30 am | |
| Bernd Walter | Mar 28, 2004 2:49 am | |
| Sam Lawrance | Mar 29, 2004 6:33 pm | |
| M. Warner Losh | Mar 29, 2004 6:44 pm | |
| Bernd Walter | Mar 30, 2004 12:41 am | |
| M. Warner Losh | Mar 30, 2004 12:46 am | |
| Bernd Walter | Mar 30, 2004 1:13 am | |
| Sam Lawrance | Mar 31, 2004 4:55 am | |
| M. Warner Losh | Mar 31, 2004 9:11 am | |
| Bernd Walter | Mar 31, 2004 10:16 am |
| Subject: | usbd config file parse behaviour | |
|---|---|---|
| From: | Bernd Walter (tic...@cicely12.cicely.de) | |
| Date: | Mar 31, 2004 10:16:31 am | |
| List: | org.freebsd.freebsd-hackers | |
On Wed, Mar 31, 2004 at 09:32:11AM -0700, M. Warner Losh wrote:
: I agree that it's bad to yank a device from under ugen automatically and : reattach it to a better match.
I think it is good. Really. However, ugen should mark the device busy when it is opened, and mark it as unbusy as closed and the reprobe shouldn't happen if the device is busy. Otherwise, there's no harm. ugen2 goes away, who cares. ugen0, ugen1, and ugen3 would still be there. However, if a device is in use, the probe routines of other divices may interfere.
ugen has a busy flag in his softc.
Part of the problem is we can't tell a driver 'detach if you aren't busy' vs 'detach now, your hardware is gone or about to be gone'. Maybe we should fix that at the same time. There's also a desire from the hot-plug bus people to have a 'quiesce' the device, which is similar to the current suspend method, but with different semantics (quiesce means stop using the hardware, while suspend says put the hardware to sleep).
Yes - a generic way would be best. And of course reprobe is not everything. In the USB as well as in the hot-plug PCI case there is a need for functions to disable/enable ports/slots manually - I think that fits with what you mean by 'quiesce'? If someone with more knowledge about the generic part could implement this then I could do the USB specific part.
: How about adding a new ioctl on /dev/usb, eg USB_REPROBE to reset a device : if a better match exists?
I don't want this to be USB specific. usb has enough kludgy hacks. That's why we're in this mess. If we do something like this, then we should do it for all devices on all busses.
: Could tack an option on to usbdevs to call it on requested devices.
Absolutely not. We want uniform behavior. It would be a nightmare to manage a huge table in the kernel with exceptions.
usbdevs is not the right tool for this kind of functionality anyway. devinfo -v with the usb devd support is already more generic then usbdevs. Meating up the informations is simple once there is no static size limit. A userland tool for reprobe should be named more like devctl and be able to operate on the whole device tree.
-- B.Walter BWCT http://www.bwct.de tic...@bwct.de in...@bwct.de